html国际化需严格校验lang和dir属性：lang必须符合bcp 47标准并显式设于根标签及所有语义化文本元素，缺失或错误会导致语音合成、字体回退异常；dir须与文本方向匹配，rtl语言需显式声明dir="rtl"，混合内容用dir="auto"；动态生成时禁止拼接未过滤的用户输入，避免xss与渲染错乱。
HTML国际化（i18n）本身不直接导致安全漏洞，但代码审查时若忽略语言相关实现细节，会暴露可访问性缺陷、SEO降权、多语言混杂导致的渲染异常，甚至间接引发XSS——比如动态插入lang值或dir属性时未校验。
检查lang属性是否缺失或硬编码错误
浏览器靠lang决定语音合成、字体回退、断字规则；缺失或错写会导致屏幕阅读器读音错误、中文显示为西文字体、搜索排名下降。
-
lang必须出现在根标签上，且值需符合BCP 47标准（如zh-CN、en-US），不能写成zh或chinese - 动态生成页面时，常见错误是把用户语言偏好（如
req.headers['accept-language']）直接拼进lang="xxx"，未过滤非法字符（如" onerror=alert(1)） - 多语言站点若用JS切换语言，需同步更新
document.documentElement.lang，否则DOM树与实际内容语言不一致
验证dir属性是否与文本方向匹配
阿拉伯语、希伯来语等RTL（right-to-left）语言需显式声明dir="rtl"，否则布局错乱、表单光标偏移、按钮图标顺序颠倒。
- 仅靠CSS
direction: rtl不够——它只影响盒模型，不改变语义层级和键盘导航顺序 - 若页面混合LTR/RTL内容（如中英混排+阿拉伯数字），应为局部容器加
dir="auto"，由浏览器自动推断，而非统一设dir="ltr" - 框架中用
v-bind:dir或ngClass动态绑定时，值必须来自可信枚举（['ltr', 'rtl', 'auto']），禁止直接映射用户输入
识别meta charset与实际编码不一致问题
HTML声明<meta charset="UTF-8">但服务端返回Content-Type头为ISO-8859-1，或文件实际保存为GBK，会导致中文乱码、表单提交字段截断、JS字符串解析失败。
- 用W3C Validator验证时，若报
Character encoding mismatch，说明HTTP头、BOM、meta三者不统一 - 特别注意：某些CMS导出HTML时会自动插入
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">，覆盖原始UTF-8声明 - Node.js后端若用
res.send()返回HTML字符串，需确保res.setHeader('Content-Type', 'text/html; charset=utf-8')显式设置，否则依赖默认值
排查多语言资源加载中的路径和fallback风险
前端通过fetch('/i18n/en.json')加载翻译包时，若URL拼接用户语言参数且无白名单校验，可能触发路径遍历或CORS泄露。
- 错误示例：
fetch(`/i18n/${navigator.language}.json`)—— 攻击者可伪造navigator.language = '../../../etc/passwd' - 正确做法：将语言代码映射到固定键值（如
{'zh-CN': 'zh', 'en-US': 'en'}），再拼接路径 - 未提供fallback语言（如
en.json缺失时未降级到en-US.json）会导致部分文案空白，破坏UI完整性
最易被忽略的是lang和dir的组合效应：比如这种矛盾声明，浏览器虽能容错，但AT（辅助技术）行为不可预测，且W3C Validator不会报错——必须人工核对。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
