用lang属性标记导航语言、语言切换按钮置于nav外、切换必须重载页面并配齐hreflang标签，才能实现语义正确且SEO友好的多语言导航。
直接用 lang 属性 + 语义化 <nav></nav> + 独立语言切换逻辑，就能撑起多语言导航，不需要框架或 i18n 库——前提是别把语言切换和路由、内容翻译混为一谈。
如何用 lang 属性标记不同语言的导航项
浏览器和屏幕阅读器靠 lang 判断文本发音与排版规则（比如阿拉伯语右对齐、中文标点避头尾），不是装饰属性。导航里混排中英文时，必须给每个语言片段显式声明：
<nav lang="zh-CN"><a href="/zh/home">首页</a></nav><nav lang="en-US"><a href="/en/home">Home</a></nav>- 如果同一
<nav></nav>内含多语言链接，不能只在根上设lang，得逐个包裹：<li><a lang="ja" href="/ja/top">トップ</a></li> - 错误写法：
<nav lang="zh-CN"><a href="/en/home">Home</a></nav>—— 这会让读屏软件用中文音读 “Home”，语义错乱
语言切换按钮该放在 <header></header> 还是 <nav></nav> 里
放在 <nav></nav> 外部更合理。语言切换本质是站点级操作，不属于导航内容本身；强行塞进 <nav></nav> 会干扰语义结构，也影响 SEO 对导航意图的理解。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 推荐结构：
<header><nav>...</nav><div class="lang-switcher"> <button data-lang="zh">中文</button><button data-lang="en">English</button> </div></header> - 如果必须放导航内（如某些设计规范要求），用
<div role="none"> 包裹按钮，明确告诉辅助技术“这不是导航项” <li>避免用下拉菜单实现语言切换：移动端点击区域小、iOS Safari 容易触发误触、无障碍支持差；纯按钮+CSS定位更稳</li> <h3>切换语言时要不要重载整个页面</h3> <p>绝大多数静态导航场景，**必须重载**。HTML 导航链接的 <code>href指向的是不同语言版本的独立 HTML 文件（如/zh/about.html和/en/about.html），不刷新就无法保证lang、hreflang、title等全局属性同步更新。立即学习“前端免费学习笔记（深入）”；
- JS 动态替换文字内容（比如只改
<a></a>文本）是典型陷阱：URL 不变、lang不变、SEO 元素丢失、后退键失效 - 真要无刷新切换，得配套服务端支持（如同一路由返回不同语言 HTML）+ 客户端维护完整语言状态 + 手动同步所有
lang、hreflang、meta name="description"等 - 检查点：切换后查看页面源码，确认
、<link rel="alternate" hreflang="xx">是否已更新
最易被忽略的一点：多语言导航不是“把文字翻成英文就行”，
hreflang标签和<link rel="alternate">关系声明必须配齐，否则搜索引擎根本分不清哪个 URL 对应哪种语言——这比样式错位更致命。 - JS 动态替换文字内容（比如只改
