仅在JavaScript被完全禁用或浏览器不支持脚本时生效，响应用户手动关闭JS或极简环境两种确定性场景，不处理加载失败、执行错误、CSP拦截等运行时问题。

标签只在 JavaScript 被完全禁用（如用户手动关闭）或浏览器根本不支持脚本时才生效——不是加载失败、不是执行报错、不是 CSP 拦截，而是浏览器压根不解析任何 <script></script> 标签。它不是“JS 出问题了就显示”，而是“JS 不存在了才显示”。

为什么 不会响应 JS 加载失败

常见误解是把它当“JS 加载异常提示”。比如 CDN 挂了导致入口脚本没拉下来，页面白屏，但 依然不出现——因为浏览器仍处于“JS 启用状态”，只是网络没拿到代码。

• 真正能捕获加载失败的，是 <script onerror></script> 或 addEventListener('error', ...) 监听 <script></script> 标签本身
• 对 fetch 超时、document.write 报错、addEventListener 绑定失败等运行时问题完全无感
• CSP 策略阻止内联脚本？只要浏览器还在尝试执行 <script></script>，它就不会触发

在 和 中的行为差异

HTML5 允许它出现在两个位置，但渲染逻辑完全不同：

• 放在 ：只能包含 、、；放
  

  JavaScript 测试模式

  使用 Jest、Vitest 和 Testing Library 实施全面的测试策略，包括单元测试、集成测试和端到端测试，涵盖模拟、测试夹具和测试驱动开发。在编

  下载
  或文本会被忽略，甚至导致解析错误
• 放在 ：可放任意流式内容（
  、、），正常参与文档流渲染
• 想给用户看提示文字？必须放 ；想 fallback 到纯 CSS 主题或基础 SEO meta？可放

哪些场景下 实际有用

它的价值集中在确定性极强的兜底边界，不是通用降级方案：

• 企业内网强制禁用 JS 的浏览器环境（如某些金融/政务终端）
• CLI 浏览器（Lynx）、无障碍阅读器、部分搜索引擎爬虫直读 HTML（Googlebot 已能执行 JS，但 Bingbot 或旧版爬虫仍可能依赖）
• 提供静态替代链接（如跳转到 SSR 渲染的备用页）或语义化文本摘要（非重复、非广告、有 alt 的 ）
• 注意： 里放 <script></script> 或 完全无效——内部所有脚本都会被跳过

最容易被忽略的兼容与可访问性细节

它存在 ≠ 可访问性自动提升。很多团队放完 “请启用 JavaScript” 就以为完事了：

• 内容若没有语义化标签（比如用
  包文字而非

  ）、缺 alt 文本、链接无明确目的（如 “点击这里”），对屏幕阅读器反而更难理解
• XHTML 完全不支持 ，若项目需 XHTML 兼容，必须移除或改用服务端逻辑判断
• 多个 块可以共存，但每个都只响应全局 JS 状态，无法按模块独立控制

真正难的不是写这个标签，而是想清楚：当 JS 彻底消失时，用户最需要看到的那几行字、那个链接、那张图，是否真的提供了有效路径，而不是一句空洞的提醒。