标签配合 aria-live 是最语义正确、可访问性达标且浏览器原生支持的方案，但需正确设置 aria-live="polite" 和 role="status"，用 textcontent 赋值防 xss，并通过 css 自定义属性适配深色模式。
直接用 <output></output> 标签配合 aria-live 是最语义正确、可访问性达标、且浏览器原生支持的方案；但多数人误把它当普通容器用，结果读屏器不播报、深色模式失效、XSS 风险藏得深。
为什么不用 alert() 或 confirm() 显示成功消息
这两个函数会阻塞 JavaScript 主线程，用户点确定前整个页面冻结。移动端 Safari 可能静默拦截，Chrome 95+ 已禁用 prompt()；它们也不支持 HTML 内容、无法控制样式、不能适配深色模式。生产环境必须规避。
-
alert("操作成功")在表单提交后调用，会导致后续清空表单、滚动定位等逻辑卡住 - 即使只用于调试，传入对象或数组会变成
[object Object]，掩盖真实返回结构 - 没有
aria-live，依赖读屏器的用户完全感知不到状态变化
<output></output> 的正确用法和常见翻车点
<output></output> 是 HTML5 专为“计算结果”和“操作反馈”设计的语义化标签，不是 <div> 的轻量替代品。它默认内联显示，IE 全系不识别但降级安全（渲染为普通文本），Safari ≤12.1 对 <code>for 属性支持弱，但日常状态提示无需 for 也能用。
- 初始内容直接写死：
<output id="status">–</output>，比 JS 动态注入更轻、更可靠 - 必须加
aria-live="polite"和role="status"，否则屏幕阅读器不会主动播报 - 更新时优先用
textContent赋值，避免innerHTML引入 XSS 风险（尤其当文案来自 API 响应） - 别给
<output></output>加disabled—— 浏览器会忽略，还可能破坏焦点逻辑
CSS 控制颜色与深色模式兼容的关键细节
硬写 color: #28a745 在深色背景上对比度不足（WCAG 要求 ≥4.5:1），甚至不可见。也不能依赖 prefers-color-scheme 自动切色——它只管系统级文字/背景主色，状态色需主动控制。
- 用 CSS 自定义属性：
color: var(--success-text, #28a745);，并在:root或主题 class 中定义变量 - 深色模式下推荐更亮的绿色，比如
#4CAF50，确保浅色背景和深色背景都满足对比度 - 禁止写
style="color:green"—— 无法被主题切换覆盖，也难做可访问性检测 - 如果项目用 Bootstrap，直接复用
text-success类，别另起一套命名
服务端渲染或动态插入时的安全红线
后端模板（如 EJS、Jinja）拼接成功文案时，若未转义用户输入或 API 返回内容，<output></output> 同样会执行恶意脚本。一个 <img src="x" onerror="alert(1)"> 就能让绿色提示变成 XSS 入口。
- EJS 中必须用
（带等号），禁用 - Jinja 中用
{{ text | escape }}，而非{{ text | safe }} - 若文案含链接，白名单过滤协议（仅允许
https://）、域名和路径，不放行任意 HTML - 前端 fetch 成功后更新
<output></output>，也要先对data.message做textContent赋值，而非innerHTML
真正容易被忽略的是 aria-live 的触发时机：它只在 DOM 文本节点内容变更时生效，不是 class 切换或 display 改变就能触发。很多团队写了 output--success 类，却忘了 textContent 没变，读屏器就永远沉默。
