lang属性必须使用IANA注册值（如zh-CN），禁用cn、ch等简写，否则导致屏幕阅读器发音不准、Chrome翻译按钮不出现、搜索引擎语言识别失败，IE及旧Safari甚至退化至怪异模式。
lang 属性必须用 IANA 注册值，不能简写
很多团队把 lang="zh" 当成“够用”，实际会导致屏幕阅读器发音不准、Chrome 翻译按钮不出现、搜索引擎语言识别失败。IE 和旧 Safari 甚至会退化到怪异模式——不是“翻译不好”，是根本没触发翻译逻辑。
- 中文站点固定用
zh-CN（简体大陆）、zh-TW（繁体台湾）、zh-HK（繁体香港），不能写cn、ch或zh - 多语言页面必须动态改
document.documentElement.lang，不能只靠模板里静态写死 - 服务端渲染（SSR）时，lang 值必须和真实语言一致，否则 hydration mismatch 会报错
meta charset 必须在 head 最开头，且不能有前置内容
<meta charset="UTF-8"> 不是“加了就行”，它必须是 里的第一个标签，前面不能有任何东西——包括空格、BOM、注释、<script></script> 或 <style></style>。否则浏览器会在解析到它之前，按系统默认编码（如 Windows-1252 或 GBK）解码前面的 <title></title>，造成标题乱码，且 JS 无法修复。
- VS Code 默认保存可能带 BOM，需手动选 “UTF-8 without BOM”
- Sublime / Notepad++ 同样要确认“UTF-8”，而非“UTF-8 with BOM”
- 检查最终 HTML 输出：用 Chrome DevTools → Network → Headers → Response Headers，确认
Content-Type包含charset=UTF-8，且与<meta>一致
form 提交必须显式声明 accept-charset
即使页面已设 <meta charset="UTF-8">，<form method="post"></form> 在部分 Safari 和旧 Android 浏览器中仍可能用 ISO-8859-1 编码提交中文，导致后端收到乱码。这不是浏览器 bug，是规范允许的 fallback 行为。
- 每个
<form></form>都要加accept-charset="UTF-8"，不能依赖 meta 继承 - AJAX 提交（如 fetch）需手动设置 header：
headers: { 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' } - 后端也得配合：PHP 要设
mb_internal_encoding('UTF-8')，Node.js Express 要确保express.urlencoded()未覆盖 encoding
团队落地靠自动化，不是靠文档
光写 Wiki 没用。新人第一天写 ，没人提醒，错误就进了 Git。真正起效的是编辑器和 CI 里的硬约束：
立即学习“前端免费学习笔记（深入）”；
- Prettier + VS Code
editor.formatOnSave强制格式，但不校验 lang 或 charset —— 这块得靠 ESLint 插件或自定义 HTML validator - husky + lint-staged 在 pre-commit 阶段跑脚本，检查
lang是否匹配正则^zh-[CN|TW|HK]$、meta charset是否在 head 第一行 - CI 流水线里加 HTML validator（如 html-validate），对
doctype位置、lang值、meta charset顺序做 fatal error 拦截
最常被忽略的是 BOM 和空格——它们看不见，却能让整个国际化链路在第一字节就断掉。
