當前負責的項目主打海外業務，總免不了和多語言打交道。但最近我在Vite+Vue3+Element Plus技術棧的項目裏，遇到了一個堪稱“玄學”的bug——Chrome瀏覽器自帶翻譯功能，居然能把表格裏的數字ID直接改了！從印度同事到國內運營，兩次觸發都讓我摸不着頭腦，今天把整個過程記錄下來，求大佬們看看這到底是怎麼回事。
一、兩次“詭異漂移”：翻譯按鈕成了ID篡改器
我們的後台管理系統很明確：部分頁面根元素設為lang="zh"（中文界面），部分設為lang="en"（英文界面），語言標識沒搞混也沒遺漏。
第一次：印度同事的英文翻譯觸發
年初，負責海外業務的印度同事反饋：“搜索出來的廣告數據有問題，Ad ID從10111872變成10111873了”。我第一時間查接口，返回的ID明明是正確的10111872；再看前端代碼，就是最常規的Element Plus表格用法，沒有任何多餘計算。
遠程連接他的電腦才發現，他把中文界面用Chrome右鍵翻譯成了英文——我讓他關閉翻譯功能刷新頁面，ID瞬間恢復10111872；重新開啓翻譯，數字又跳成10111873。當時以為是個案，沒深查，只提醒他暫時不用翻譯。
第二次：國內運營的中文翻譯觸發
前天，國內運營同事在英文界面操作時，把頁面翻譯成中文，結果歷史重演：表格裏的ID 20011872直接變成20011873。這次我確定不是偶然，而是Chrome翻譯和Element Plus表格的“兼容性陷阱”。
貼一下我們的核心代碼，真的就是最基礎的el-table配置，沒有任何花裏胡哨的操作：
<template>
<div lang="zh">
<el-table
:data="orderTableData"
border
stripe
style="width: 100%"
>
<!-- 普通列：Ad Name翻譯正常，無異常 -->
<el-table-column
label="Ad Name"
prop="adName"
width="200"
/>
<!-- 異常列：開啓Chrome翻譯後，該列adId數值會發生漂移（如10111872→10111873） -->
<el-table-column
label="Ad ID"
prop="adId"
width="200"
/>
</el-table>
</div>
</template>
<script setup>
import { ref } from 'vue';
import { ElTable, ElTableColumn } from 'element-plus';
// 模擬接口返回數據，真實場景為接口拉取
const orderTableData = ref([
{ adId: 10111872, adName: "Summer Promotion", status: "已上線" },
{ adId: 10111172, adName: "New Product Launch", status: "待審核" },
{ adId: 10111272, adName: "Member Exclusive", status: "已下線" }
]);
</script>
二、排查過程：繞了一圈，排除所有常規可能
為了找到問題根源，我幾乎把能排查的點都過了一遍，但結果全是“正常”：
- 接口與數據層面：Network面板反覆確認，接口返回的adId是正確值，沒有被篡改；前端接收數據後也沒有做任何運算，直接賦值給表格數據源。
- 本地與多設備測試：我換了自己的Windows、MacBook，又找了5個同事用不同系統（Windows10/11、macOS）測試，無論怎麼開翻譯，ID都紋絲不動。
- 瀏覽器環境排查：遠程檢查觸發異常的兩台電腦，Chrome都是最新版本，沒有安裝任何可疑插件，清除緩存、重啓瀏覽器後，問題依然存在。
- 代碼與依賴檢查：Element Plus版本是穩定版，沒有兼容性問題；表格沒有自定義渲染函數，也沒有使用任何修改DOM的指令或插件。
排查到最後，我甚至懷疑是不是“量子糾纏”——直到發現兩次異常都有一個共同觸發條件：Chrome瀏覽器開啓頁面翻譯。
三、解決方案：給ID加“翻譯豁免權”
既然確定是翻譯功能搞的鬼，就順着這個方向找解決方案。查HTML標準發現，HTML5原生有個translate屬性，專門控制元素是否參與翻譯——給元素加translate="no"，瀏覽器就會跳過該元素的翻譯處理。
針對表格ID列做了修改，核心是給ID所在的元素添加這個屬性，修改後的代碼如下：
<!-- 修復後的ID列代碼，其他列不變 -->
<el-table-column label="Ad ID" width="200">
<template #default="scope">
<!-- 關鍵修復：添加translate="no"，禁止Chrome翻譯該節點，避免ID數值被篡改 -->
<span class="ad-id" translate="no">{{ scope.row.adId }}</span>
</template>
</el-table-column>
把修改後的代碼發給出問題的同事，他們開啓翻譯再測試——ID穩穩地顯示正確值，再也沒有出現“漂移”。這個臨時方案雖然解決了問題，但我的疑惑更重了。
四、疑惑：這到底是Chrome的bug，還是我漏了什麼？
雖然問題解決了，但幾個疑問始終縈繞在我心頭，想借這篇文章問問各位大佬：
- 為什麼只有特定設備觸發這個問題？同樣的Chrome版本、同樣的操作，大部分設備正常，而觸發的同事電腦上設備必現，難道和瀏覽器的某些隱藏配置有關？
- 為什麼ID篡改有固定規律？兩次異常都是ID末尾+1，不是隨機亂改，這背後有沒有特定的DOM處理邏輯？
- 這是Chrome翻譯的bug，還是Element Plus表格的DOM結構容易被翻譯器誤判？有沒有更根本的解決辦法，而不是給每個關鍵節點加豁免？
