前端国际化不入侵业务代码的轻量级i18n方案：DOM文本节点扫描替换

搞国际化的时候最烦的就是业务代码里到处塞t(xxx)尤其是一堆历史项目改起来恨不得重写。我这边就是被这种需求逼出来的一个内部中后台系统页面多、文案杂、排期还紧正经引入 i18n 框架再一个个改模板根本来不及。后来索性自己写了个“偷懒版”国际化组件核心思路就一句话不入侵业务代码靠扫描 DOM 文本节点做替换。说白了就是页面里该写中文还写中文我这边通过一个轻量级脚本把中文替换成目标语言。这篇文章就把这套组件的设计思路、核心实现、踩坑记录完整拆开讲适合接手老项目、但又没时间大改的团队参考也适合想在项目里快速落地 i18n 的同学抄作业。1. 整体设计与思路拆解1.1 为什么需要“偷懒版”动态扫描替换常见的 i18n 方案比如 vue-i18n、react-intl核心模式都是先把文案抽离成 key然后在模板里逐个替换。这个方案本身没毛病但对于存量项目问题就很现实了模板文件几十个每个文件里十几处中文要一个萝卜一个坑地改成$t(xxx)工作量看着不大实际上改完还要回归测试稍微漏一处页面上就是中英混排。我当时算了下光是一个订单列表页涉及的中文文案就有八十多处其中还有不少是动态拼接的比如“共 {count} 条记录”这种要改起来更麻烦。与其在业务代码里折腾不如换一个思路既然浏览器最终渲染的是 DOM 文本节点那我直接在文本节点这一层做手脚。页面里保留中文原文脚本跑起来的时候按照语言包里的映射关系把文本节点里的中文替换成对应语言。业务代码完全不用动甚至页面结构都不用动。这个思路听起来有点“野”但实用性很强尤其适合这几类场景历史遗留项目页面多、组件杂没有统一文案管理快速原型或 demo需要短时间内给客户看多语言效果内容型页面以静态文案为主动态交互相对少团队不想引入重量级依赖也不想改变现有开发习惯。当然它也有明显的边界后面我会专门讲哪些场景不适合这么搞。1.2 核心设计目标业务代码最小侵入“偷懒版”这三个字落到代码设计上就是一条铁律原则上不要求业务代码做任何改动。要做到这一点就要把能力边界划清楚。我给自己定了这几个目标零 API 依赖业务页面里不引入任何初始化代码也不要求在模板里写>// lang.zh-CN.js const zhCN { 首页: 首页, 订单管理: 订单管理, 共 {count} 条记录: 共 {count} 条记录, 新增: 新增, 删除: 删除, 确定要删除这条记录吗: 确定要删除这条记录吗, 加载中...: 加载中..., 操作: 操作 }; // lang.en-US.js const enUS { 首页: Home, 订单管理: Orders, 共 {count} 条记录: {count} records in total, 新增: Add, 删除: Delete, 确定要删除这条记录吗: Are you sure you want to delete this record?, 加载中...: Loading..., 操作: Actions };你可能注意到了key 直接用的就是中文原文。这样做的好处是业务代码里是什么样语言包里就是什么样维护的时候对着页面看就行不需要再去查代码里的 key。坏处也有如果文案稍微改了一个字比如“订单管理”改成“订单管理中心”key 就匹配不上了需要同步改语言包。这个问题在实际使用中确实会碰到后面我会讲处理方法。考虑到实际项目里文案很多我会建议把语言包按页面或模块拆成多个文件最后合并到一起。比如// index.js import order from ./modules/order; import user from ./modules/user; import common from ./modules/common; export default { ...common, ...order, ...user };这样多人协作时冲突会少很多维护起来也清晰。2.2 文本节点扫描的完整实现核心逻辑其实不复杂遍历 DOM 树找到文本节点拿文本内容跟语言包里的 key 做匹配匹配上了就替换。但实际写起来有几个细节必须处理到位。先看基础版实现class LazyI18n { constructor(options {}) { this.lang options.lang || zh-CN; this.dict options.dict || {}; this.placeholderRegex /\{(\w)\}/g; this.observer null; this.processedNodes new WeakSet(); this.init(); } // 切换语言 setLang(lang) { if (!this.dict[lang]) { console.warn([lazy-i18n] Language pack ${lang} not found); return; } this.lang lang; this.scan(document.body); localStorage.setItem(lazy-i18n-lang, lang); document.documentElement.setAttribute(lang, lang); } // 根据 key 获取翻译文本支持占位符替换 t(key, params) { const langPack this.dict[this.lang] || {}; let text langPack[key] || key; if (params) { text text.replace(this.placeholderRegex, (match, name) { return params[name] ! undefined ? params[name] : match; }); } return text; } // 扫描 DOM 中的文本节点 scan(root document.body) { const walker document.createTreeWalker(root, NodeFilter.SHOW_TEXT, { acceptNode: (node) { // 跳过 script 和 style 标签内部文本 if (node.parentElement [SCRIPT, STYLE].includes(node.parentElement.tagName)) { return NodeFilter.FILTER_REJECT; } return NodeFilter.FILTER_ACCEPT; } }); const textNodes []; while (walker.nextNode()) { textNodes.push(walker.currentNode); } textNodes.forEach(node { this.replaceNodeText(node); }); } replaceNodeText(node) { const text node.nodeValue; if (!text || !text.trim()) return; // 已经被处理过且内容未变化的跳过 if (this.processedNodes.has(node) node.nodeValue text) { return; } const langPack this.dict[this.lang] || {}; let newText text; // 长文本优先匹配 const keys Object.keys(langPack).sort((a, b) b.length - a.length); keys.forEach(key { if (newText.includes(key)) { newText newText.split(key).join(langPack[key]); } }); if (newText ! text) { node.nodeValue newText; } this.processedNodes.add(node); } init() { // 读取本地存储的语言设置 const savedLang localStorage.getItem(lazy-i18n-lang); if (savedLang this.dict[savedLang]) { this.lang savedLang; } // 监听动态内容 this.observer new MutationObserver((mutations) { mutations.forEach(mutation { if (mutation.type childList) { mutation.addedNodes.forEach(node { if (node.nodeType Node.TEXT_NODE) { this.replaceNodeText(node); } else if (node.nodeType Node.ELEMENT_NODE) { this.scan(node); } }); } }); }); this.observer.observe(document.body, { childList: true, subtree: true }); // 首次扫描 this.scan(document.body); document.documentElement.setAttribute(lang, this.lang); } } // 使用 const i18n new LazyI18n({ lang: localStorage.getItem(lazy-i18n-lang) || zh-CN, dict: { zh-CN: zhCN, en-US: enUS } });这段代码里值得注意的几点长文本优先匹配拿 key 时按长度从长到短排序避免“删除”先于“确定要删除这条记录吗”匹配导致短文本替换后长文本的 key 被破坏。WeakSet 记录已处理节点防止重复扫描时反复替换尤其是切换语言回来时能避免文本被二次替换造成错乱。MutationObserver 监听动态节点现代前端页面基本都有动态渲染内容如果不监听后来加载的节点就不会被翻译。2.3 处理动态内容与占位符动态内容是扫描替换方案最容易翻车的地方。比如说“共 128 条记录”这串文本里既有固定文案“共”“条记录”又有变量“128”。如果语言包按固定文案匹配“共 128 条记录”这个组合是不存在的因为数字一变文本就变了。我的处理方式有两种第一种把变量替换成占位符再匹配。扫描文本节点时先用正则把数字、金额等变量提取出来替换成占位符后再去语言包里找const dynamicRegex /(\d(?:\.\d)?)/g; function normalizeText(text) { return text.replace(dynamicRegex, {count}); }比如“共 128 条记录”会被标准化成“共 {count} 条记录”然后就能匹配上语言包里的 key 了。不过这样做有个问题如果一页里有多个数字变量全都归一化成了{count}翻译结果可能张冠李戴。所以这种方法只适用于数字出现位置比较固定的场景。第二种不建议的做法直接改业务代码。如果某处的动态内容实在复杂例如“订单号 123456 已提交预计 3 天内发货”这种混合了多个位置变量的长句扫描替换很难优雅处理。我个人的经验是在这类极少数场景里允许业务代码“破例”调用一次i18n.t()方法。偷懒不等于绝对不能改代码关键是把改动面控制在最小范围。实际操作中我会在语言包里支持这样的写法const enUS { 共 {count} 条记录: {count} records in total, 订单号 {orderNo} 已提交预计 {days} 天内发货: Order {orderNo} submitted, estimated delivery within {days} days };然后在replaceNodeText里做占位符还原// 解析文本中的实际数值 function parseDynamicText(text, key) { const pattern key.replace(/\{(\w)\}/g, (.?)); const regex new RegExp(^ pattern $); const match text.match(regex); if (!match) return null; const params {}; const keyNames [...key.matchAll(/\{(\w)\}/g)].map(m m[1]); keyNames.forEach((name, index) { params[name] match[index 1]; }); return params; }不过说句实在话这套逻辑在纯文本节点上跑简单文案匹配没问题复杂度一高还是有风险。所以原则是能静态匹配的尽量静态匹配不能的就用占位符占位符还搞不定的那就老老实实在业务代码里调用一次翻译函数。2.4 属性节点的国际化处理文本节点解决了但页面上还有不少文案是放在 HTML 属性里的最常见的就是placeholder、title、aria-label。这些地方如果不处理一个页面翻译完搜索框里还是中文提示体验很割裂。处理思路和文本节点类似扫描元素节点检查它有没有匹配语言包的属性。我会在组件里维护一份“需要翻译的属性名列表”const ATTRIBUTE_KEYS [placeholder, title, aria-label, alt]; function scanAttributes(root) { const elements root.querySelectorAll(*); elements.forEach(el { ATTRIBUTE_KEYS.forEach(attr { const value el.getAttribute(attr); if (!value) return; const translated i18n.t(value); if (translated ! value) { el.setAttribute(attr, translated); } }); }); }这里有个细节不要一股脑地把所有属性都翻译了。像id、class、>window.LAZY_I18N_DICT { zh-CN: zhCN, en-US: enUS };组件初始化时会自动读取这个全局变量也可以直接在构造函数里传入。第三步执行初始化。在body加载完后调用window.lazyI18n new LazyI18n({ dict: window.LAZY_I18N_DICT, lang: localStorage.getItem(lazy-i18n-lang) || zh-CN });就这三步页面里所有能匹配到的中文文本就会被自动替换成目标语言。第一次跑起来的时候看着满屏的中文瞬间变成英文还是有点成就感的。如果你要做得更完善一点可以加一个语言切换按钮的绑定逻辑document.getElementById(lang-switch-en).addEventListener(click, () { window.lazyI18n.setLang(en-US); }); document.getElementById(lang-switch-zh).addEventListener(click, () { window.lazyI18n.setLang(zh-CN); });点击切换后整个页面会在不刷新的情况下完成语言切换体验跟传统 i18n 是接近的。3.2 完整示例一个订单列表页的实战光讲理论终归浅显我用一个实际例子来演示整个效果。假设有一个订单列表页面HTML 结构长这样div classpage h1订单管理/h1 div classtoolbar input typetext placeholder请输入订单号 / button classsearch-btn搜索/button button classdelete-btn批量删除/button /div table thead tr th订单号/th th客户名称/th th金额/th th状态/th th操作/th /tr /thead tbody idorder-list tr tdORD-2024001/td td张三/td td1,299.00/td td已发货/td tda href#查看/a a href#删除/a/td /tr /tbody /table div classpagination共 1 条记录/div /div语言包配置如下const enUS { 订单管理: Order Management, 请输入订单号: Enter Order No., 搜索: Search, 批量删除: Batch Delete, 订单号: Order No., 客户名称: Customer, 金额: Amount, 状态: Status, 操作: Actions, 查看: View, 删除: Delete, 已发货: Shipped, 待付款: Pending Payment, 已完成: Completed, 共 {count} 条记录: {count} record(s) in total };注意表格里的“删除”和“批量删除”同时存在。如果语言包里的“删除”排在“批量删除”前面页面渲染时“批量删除”可能先匹配到“删除”被翻译成“Batch Delete”然后“删除”又翻译成“Delete”结果就变成了“Batch Delete”而不是“Batch Delete”——实际上“批量删除”整体在语言包里也有但因为顺序问题可能被拆开处理。这就是我前面说的“长文本优先匹配”要解决的坑。在replaceNodeText中我会把 key 按长度排序这个排序逻辑不能省。满屏文案扫描下来肉眼可见的处理顺序是先长后短从完整句子到短语再到单词这样能最大程度避免子串误匹配。再来看数字动态内容。div classpagination共 1 条记录/div这个文本正常的 key 匹配是匹配不到“共 1 条记录”的。按前面 2.3 节的方法我会先做归一化处理把数字提取出来替换成{count}再去语言包里找。所以严格来说replaceNodeText里的匹配逻辑应该是这样的function doReplace(node, langPack) { const text node.nodeValue; const normalized text.replace(dynamicRegex, {count}); // 优先用原文匹配 if (langPack[text]) { return langPack[text]; } // 再用归一化文本匹配 if (langPack[normalized]) { const params {}; const values [...text.matchAll(dynamicRegex)].map(m m[0]); const keyNames [...normalized.matchAll(/\{(\w)\}/g)].map(m m[1]); keyNames.forEach((name, index) { params[name] values[index]; }); return langPack[normalized].replace(/\{(\w)\}/g, (match, name) params[name] ?? match); } return text; }这样语言包里只需要维护带占位符的 key实际渲染时再把具体数字填回去既保证了翻译效果又不影响原文里的动态内容。引入组件后这个页面的运行效果就是中英文切换按钮一点表格标题、按钮、搜索框提示、状态列、分页信息全部跟着变而业务代码一行没改。整个组件文件压缩后不到 4KB没有任何外部依赖。3.3 性能优化与边界控制扫描 DOM 听起来是个耗费性能的操作尤其是页面复杂的时候可能有几千个文本节点。刚开始我在本地测试一个一百多行的表格页面全量扫描大概花了 80ms用户几乎感知不到。但如果页面上图表、列表非常多几百毫秒的卡顿就很明显了所以在正式使用时我做了三处优化避免重复扫描整棵 DOM只有首次加载和主动切换语言时才全量扫描。动态内容由 MutationObserver 按需处理不重新遍历整个 body。跳过大段非文案区域比如图表容器、Canvas、SVG 内部文本这些区域往往不需要国际化。可以给容器加一个>let pendingNodes []; let scheduled false; function scheduleHandle(nodes) { pendingNodes pendingNodes.concat([...nodes]); if (scheduled) return; scheduled true; requestAnimationFrame(() { scheduled false; pendingNodes.forEach(node handleNode(node)); pendingNodes []; }); }我实测下来防抖之后动态内容的替换延迟最高也就一帧约 16ms用户几乎无感但 CPU 占用明显下去了。3.4 语言包自动提取的小工具这个环节算是福利。手动维护语言包固然简单但文案一多要对着页面一条条复制粘贴还是会忘记或者遗漏。我的做法是写了一个 Node.js 小脚本自动扫描项目里的 HTML / Vue 模板提取所有中文字符串生成语言包的骨架// extract.mjs import fs from fs; import path from path; const dir process.argv[2] || ./src; const output process.argv[3] || ./lang/zh-CN.generated.js; const regex /[\u4e00-\u9fa5][\u4e00-\u9fa5。、\d\w\s%¥\-.]{0,50}[\u4e00-\u9fa5】》%]?/g; function walk(dir) { let results []; const list fs.readdirSync(dir); list.forEach(file { const fullPath path.join(dir, file); const stat fs.statSync(fullPath); if (stat.isDirectory()) { results results.concat(walk(fullPath)); } else if (/\.(html|vue|jsx|tsx|js|ts)$/.test(file)) { results.push(fullPath); } }); return results; } const dict {}; const files walk(dir); files.forEach(file { const source fs.readFileSync(file, utf-8); const matches source.match(regex) || []; matches.forEach(text { dict[text.trim()] text.trim(); }); }); const outputContent const generated JSON.stringify(dict, null, 2) ;\nexport default generated;; fs.writeFileSync(output, outputContent, utf-8); console.log(Extracted ${Object.keys(dict).length} items to ${output});这个脚本提取出来的文件就是完整的 zh-CN 语言包翻译人员只需复制一份改成 en-US把值翻译一下就行。当然自动提取会捞到一些不是 UI 文案的文本比如配置信息、注释所以不建议直接在生产使用而是拿来打底人工校对一轮再上线。但对比手抄文案效率提升真的不是一点半点。4. 常见问题与排查技巧实录4.1 文本替换后又被还原的怪问题踩过最大的一个坑发生在 Vue 项目里。页面首次加载扫描替换一切正常但只要某个响应式数据一更新之前翻译过的地方又变回了中文。排查了很久才想明白原因Vue 内部维护了自己的虚拟 DOM更新视图时会根据之前的 VNode 重新渲染真实 DOM把替换后的文本节点整个替换掉恢复到原始中文。因为响应式数据没有变化时 Vue 不会重新渲染所以静态内容看起来是正常的一旦数据变化组件重渲染我替换的内容就被打回原形。针对这个问题我给出的解决方案是换一种思路工作与其替换文本节点不如拦截文本节点的变化。在 MutationObserver 回调里凡是检测到文本节点内容变成了中文也就是 key就再次触发替换逻辑。配合前面的防抖机制实际体验是“中文出现约 16ms 后立刻变成英文”肉眼几乎不可见。这个方案笨但有效。如果你用的框架是 React也类似。React 的 reconciliation 过程也会重建 DOM 节点需要同样的兜底逻辑。所以这个组件在实际项目中要做成“能扛住框架更新”的版本MutationObserver 不能只监听新增节点还需要监听所有文本节点的属性变化。4.2 文案含有特殊字符导致的匹配失败语言包里如果包含正则特殊字符比如“待定”“2024最新”在构建正则表达式或做字符串包含判断时可能出问题。我在最早版本里为了性能用了indexOf匹配后来发现没有问题但后来加了正则归一化后就踩了几个坑。比如语言包里有这么一条状态待定: Pending如果我在代码里直接把这个 key 用于new RegExp(key)括号会被当成分组正则行为完全不对。解决方式是对 key 做转义function escapeRegExp(str) { return str.replace(/[.*?^${}()|[\]\\]/g, \\$); }这个函数后续在构建动态正则时一定要加上否则你会在排查 bug 时怀疑人生。实现替换时我实际上也更倾向于用 split/join不用正则但涉及到占位符解析正则绕不开所以转义函数是必需品。4.3 文本中间被标签拆分匹配不上HTML 里经常会见到这样的写法p共 span classhighlight12/span 条记录/p从视觉上看是“共 12 条记录”但在 DOM 树里文本节点被span标签分隔成了三个部分“共 ”、“12”、“条记录”。这种情况下无论如何都没法通过单个文本节点匹配到完整的“共 12 条记录”。我的处理方案是顺着上一个或下一个兄弟节点做拼接匹配。具体实现是在扫描文本节点时对于一个匹配失败的文本节点尝试和它的兄弟文本节点合并后再匹配。因为合并逻辑要改动多个节点所以代码里需要额外记录合并范围和目标文本。不过这种方案在复杂的动态页面里偏复杂我实际建议是最好还是从模板层面把这个结构改掉用 CSS 画高亮而不是拆标签。如果实在改不了模板就只能接受局部不翻译这条属于“偷懒”方案的天然局限。4.4 逻辑冲突动态替换与框架数据绑定还有一次是在一个 AngularJS 老项目里那个项目还在用ng-bind扫描替换后页面显示正常但下次数据更新时AngularJS 的脏检查发现数据模型和 DOM 内容不一致直接报错。原因是 AngularJS 期望 DOM 文本由 scope 数据驱动外部修改 DOM 打破了它的预期。这个问题的本质是任何基于框架的数据绑定都不希望第三方脚本直接改 DOM 内容。所以在使用“偷懒版”组件前一定要搞清楚你的项目框架的更新机制。Vue、React 重渲染会覆盖Angular 系列的绑定可能直接报错。如果遇到这种框架强约束的场景我的建议是该妥协的时候要妥协。与其和框架打架不如做一层适配在框架组件里暴露一个翻译方法业务代码里把{{ 共 count 条记录 }}改成{{ $lazyT(共 {count} 条记录, { count: count }) }}。这样虽然少量侵入了业务代码但整体可控翻译效果也稳定。4.5 常见问题速查表我把使用中容易出现的问题整理成了一张表方便你快速定位问题现象可能原因解决办法页面加载后没有翻译语言包未正确挂载检查LAZY_I18N_DICT全局变量是否存在检查语言代码是否匹配部分文本翻译了部分没翻译匹配 key 顺序问题或文本被标签拆分检查语言包 key 是否和页面原文一致检查 DOM 结构动态内容更新后变回中文框架重渲染覆盖DOM在 MutationObserver 中增加文本变化监听翻译后出现重复替换切换语言多次或旧内容被反复处理使用 WeakSet 标记已处理节点切换语言前清理标记数字内容翻译成不正确的占位符归一化逻辑冲突合并相邻文本节点或调整占位符解析逻辑属性里的文案没有变化属性白名单里没有覆盖在ATTRIBUTE_KEYS中加入对应属性名页面控制台大量报错语言包里有重复 key 或非法字符检查语言包 JSON 格式跑一遍自动提取脚本做校验高亮文本/拼接内容不翻译文本节点被标签拆分尽量改模板结构或用 CSS 模拟高亮4.6 关于切换语言的体验细节最后加一条经验等你把组件跑起来后会发现语言切换的体验细节跟传统 i18n 有些不一样。因为替换是异步的在大页面上切换语言的那一帧能看到中文先闪一下再变英文。我自己优化过一版切换时先给根节点加一个透明的 class等扫描替换完再让内容显示出来。这样页面视觉上是“变暗→变亮”的效果不会看到中英混杂的尴尬瞬间。另外一个容易被忽略的点是切换语言后要手动更新html lang...属性和页面 title。这对 SEO 和辅助工具比如屏幕阅读器很重要很多人会漏掉。在setLang方法里加上两句document.documentElement.setAttribute(lang, this.lang); document.title this.t(document.title);页面 title 通常放在head里不在 body 里首次扫描扫不到所以切换时也要顺手处理一下。这些都是我实际做过一轮才补上的细节前几个版本确实被用户吐槽过“切了英文浏览器标签页还是中文”。5. 这套方案能走多远扩展与边界5.1 什么时候该换回传统 i18n 方案“偷懒版”方案不是万能的我用了一段时间后总结出几个明显的“不适合”信号页面里动态拼接文案太多到处是“XXX确定要删除吗”这类结构化文本产品对翻译准确度要求极高不能接受任何一处漏翻项目还处于早期后续会有大量新页面持续接入需要规范的 key 管理体系团队里已有一套成熟的 i18n 工具链只是当前项目还没接入。碰到这些情况我强烈建议别硬用偷懒方案。扫描替换适合“救火”不适合“长期驻扎”。长期项目还是要老老实实用 vue-i18n 或 react-intl配合构建插件的自动提取、类型提示那才是一劳永逸的做法。5.2 扩展方向从“能用”到“好用”如果你决定在项目里长期使用这套组件我推荐你按这几个方向去扩展语言包按需加载。当前的实现是把所有语言包一次性挂载如果支持几十种语言内存和带宽都会有压力。改成按需加载后用import()动态拉取语言包体验会好很多。自动提取文案的 CLI 工具。前面提到的基础提取脚本可以做进一步封装支持过滤噪声、生成 diffs、维护翻译进度统计这样翻译工作的进度就一目了然了。配合后端做语言偏好同步。当前语言偏好存在localStorage换设备就丢失了。更完善的方案是在登录成功后把语言偏好带到后端下次登录时由接口返回。持久化变更冲突检测。如果业务代码里的中文改了一个字语言包里还能不能匹配上这个问题我会在组件里加一个启动日志扫描时统计“有多少原文匹配成功、多少失败、失败的具体位置”这样每次发布后都能通过日志发现漏翻译的文本。5.3 写在最后的一点心得这个组件一开始只是我临时拼出来的工具没想过要沉淀成一篇完整的方法论。但实际用了一段时间后我发现很多团队在接到“给老项目做国际化”这种需求时第一反应都是先去引入框架然后陷入改模板的泥潭。其实有时候换个角度思考不一定要去适应框架可以让框架的产物DOM来适配你的需求。这种思路有它的糙但也确实能解燃眉之急。如果你要复刻这个方案我最想提醒你的是控制好“偷懒”的边界。文案替换可以偷懒但安全性、可维护性、回退策略必须想清楚。得在动手前就判断好这套方案适合到这个项目里的哪些模块不适合哪些模块。我给内部的建议是核心交易链路用传统方案内容展示型和后台管理型页面用扫描替换两边井水不犯河水整体效率反而最高。最后分享一个小技巧无论用哪种方案语言包里都建议给每个 key 加上注释或备注标注它出现在哪个页面、什么模块。因为时间一长你自己都会忘记当时那个“删除”到底是指表格里的操作按钮还是弹窗里的确认按钮这时候注释就是救命稻草。这算是我踩过无数次坑后最想叮嘱你的一点了。