多语言必须与响应式分离处理，采用语言子目录（如/zh/）承载静态页面，动态内容用data-i18n驱动；需服务端注入lang属性、严格区分textContent/innerHTML、兼容旧浏览器并同步所有lang值。
纯靠 CSS 媒体查询或 viewport 设置无法实现多语言，响应式解决的是「怎么在不同屏幕显示」，而多语言解决的是「显示什么内容」——两者正交，必须分开处理。最稳的落地方式是：用语言子目录结构（如 /zh/、/en/）承载完整静态页面，再叠加 data-i18n 机制处理动态内容。
为什么不能只靠响应式模板自动“适配”多语言
响应式模板本质是布局弹性 + 断点切换，它不感知语言逻辑。你写一个 @media (max-width: 768px)，它不会自动把 “Login” 变成 “登录”，也不会把日期格式从 MM/DD/YYYY 切到 YYYY年MM月DD日。强行在同一个 HTML 文件里塞多套文案，靠 JS 切换，会导致：
- SEO 抓取混乱：爬虫只看到初始语言，
hreflang标签无法声明关系 - 首屏白屏：所有文本依赖 JS 加载 JSON 后才渲染，LCP 拖慢
- 状态丢失：表单输入、滚动位置、第三方组件（如地图、图表）语言不联动
- 辅助技术失效：屏幕阅读器按
document.documentElement.lang读音，但若该属性未随内容同步更新，语音就错乱
真正可行的结构：语言子目录 + data-i18n 分层
静态页面主体走子目录隔离，动态片段（如用户欢迎语、实时通知、AJAX 加载的评论）用 data-i18n 驱动。这样既保 SEO 和首屏性能，又支持运行时局部更新。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
/（默认英文）、/zh/、/ja/下各放一套完整 HTML，内容为人工精准翻译，不是机器替换 - 每个页面的
必须由服务端根据路径注入，不能 JS 启动后才改 -
data-i18n只用于无法预生成的部分：例如<div id="user-greeting" data-i18n="welcome.user"></div> - 加载语言包时，先试
zh-Hans，再 fallback 到zh，最后退到en；fetch 失败必须有兜底占位符，避免显示welcome.user
data-i18n 实际怎么用才不出错
这个属性不是“加了就自动好”，必须配合明确规则和 DOM 更新逻辑：
立即学习“前端免费学习笔记（深入）”；
- 只对
textContent生效：<h2 data-i18n="nav.about"></h2>→ 替换文字；但placeholder要写data-i18n-placeholder="search.hint" - IE11 不支持
element.dataset.i18n，得用element.getAttribute('data-i18n')兜底 - 含 HTML 的文案（如“请阅读服务条款”）需用
innerHTML，且语言包值必须是可信字符串，否则 XSS - 动态插入的节点（弹窗、表格行），插入后必须立刻调用翻译函数，否则不会被扫描到
- 别给
<script></script>、<style></style>、<pre class="brush:php;toolbar:false;"></pre>加data-i18n——它们不渲染为可见文本
容易被忽略的关键点
多数人卡在语言检测和 lang 属性同步上。浏览器 navigator.language 返回 zh-CN，但用户可能偏好 zh-HK；安卓 WebView 常返回空字符串。更严重的是，只改 document.documentElement.lang，却不更新 <p lang="en">API</p> 这类已有 lang 的子元素，屏幕阅读器仍按旧语言朗读，字体 fallback 也错位。切换前必须遍历并选择性保留或重设这些局部 lang 值。
