国际化需剥离硬编码文本交由i18n管理，数字/日期用Intl格式化，RTL需正确设dir与CSS，大表格须流式渲染+虚拟滚动，table-layout: fixed须用col控制宽度，多级表头应降维适配移动端。
国际化不是加个 lang 属性就完事
HTML 表格本身不自带翻译能力，lang 只影响屏幕阅读器发音和字体回退，对内容翻译毫无作用。真正要让表格支持多语言，核心是把所有可读文本（表头、单元格内容、caption、aria-label）从硬编码 HTML 中剥离，交由 i18n 框架或纯 JS 管理。
常见错误：在 <th>用户名</th> 里直接写中文，然后靠 CSS 切换显示——这会导致 SEO 丢失、无法被翻译工具提取、辅助技术读错语义。
- 必须用 key 替代原文，例如
<th data-i18n="user_name"></th>，渲染时由 JS 注入对应语言文案 - 表头排序提示、空状态文案、加载占位符等动态文本，同样走 i18n key，不能拼字符串
- 数字/日期/货币格式必须用
Intl.NumberFormat或Intl.DateTimeFormat，而不是手动加逗号或写死 “2024年7月” - RTL 语言（如阿拉伯语）下，
dir="rtl"要设在<table> 上，且需配合 <code>text-align: right和direction: rtl，否则表头与数据列错位复杂表格渲染别堆 DOM，先拆结构再流式挂载
6 万行表格卡死，不是因为“表格慢”，而是你一次性调用了
innerHTML = hugeString或appendChild几万个tr。浏览器得等整块 HTML 解析完才建 DOM 树，期间主线程完全冻结。工程化关键不是“怎么优化 table”，而是“怎么绕开 table 的解析阻塞”。
立即学习“前端免费学习笔记（深入）”；
- 服务端返回 JSON 数据，前端用
document.createElement('tr')+DocumentFragment批量构建，每 500 行插入一次 - 插入后必须让出主线程：
await new Promise(r => setTimeout(r, 0))，避免连续重排 - 首屏只渲染可视区（+/-10 行），滚动时用
IntersectionObserver动态加载邻近行，即虚拟滚动 - 合并单元格（
rowspan/colspan）全量渲染时极易错位，建议只对当前可见行做逻辑合并，隐藏区用 placeholder 占位
table-layout: fixed 的宽度陷阱必须用
控制 设了
table-layout: fixed却还在每个th上写width: 20%？浏览器只认第一行（或<col>）的宽度声明，其余全是无效计算，小屏下文字撑开单元格、列宽崩坏就是这么来的。移动端尤其敏感：百分比总和超 100% 时，多余列会被压缩到 0；没设宽的列在窄屏下可能被挤成一条线。
- 用
<col style="width: 15%">显式定义每列宽度，语义清晰且无渲染干扰 - 最后一列不设宽，让它自动占满剩余空间，适应不同屏幕
- 绝对禁止在
th或td上用min-width、flex、white-space: nowrap—— 这些在table-layout: fixed下全部失效 - 真机测试时打开 Chrome DevTools → Rendering → 勾选
Paint flashing，反复闪烁的单元格说明 width 计算不稳定
多级表头和跨行合并在移动端本质不可靠
rowspan和嵌套thead在桌面端看着整齐，一到手机上就错位、边框断裂、整行消失——这不是 CSS 能修的，是表格 DOM 协议在小尺寸下的结构性失配。用户不会为“语义正确”买单，只会因“看不见数据”而离开。
- 优先把多级表头降维：用
data-label把父级标题塞进子单元格，例如<td data-label="部门/姓名">张三</td>，CSS 隐藏冗余表头，小屏只留一行 - 实在要保留合并结构，外层包
overflow-x: auto，并用@media (max-width: 480px)直接display: none掉易崩列 - 语音读屏（VoiceOver）读不出跨行关联，必须用
aria-describedby显式绑定描述 ID，否则残障用户根本不知道“该数值属于哪一行” - 维护成本高的根源不在代码量，而在结构耦合：8 列 × 20 行的表格，所有
tr写死在tbody里，改一列样式就得全局搜td:nth-child(5)—— 应该抽成<template id="data-row"></template>，JS 实例化时注入数据
- 服务端返回 JSON 数据，前端用
