strong和em用于定义文本逻辑角色而非样式：strong表信息权重，em表语气色彩；误用会导致读屏错误、seo降权及无障碍检测失败。
strong 和 em 不是用来“加粗”或“斜体”的，它们定义的是文本在句子中的逻辑角色：一个是信息权重，一个是语气色彩。选错标签，屏幕阅读器会读错、搜索引擎可能降权、WCAG 检测工具会报障。
什么时候必须用 strong？看删掉它会不会出事
不是“要不要醒目”，而是“用户跳过这段，操作是否可能失败或造成严重后果”。
- 表单错误提示里的判定词：
邮箱格式不正确→ 应该只包不正确，因为这才是触发重填的关键判断 - 权限警告中的不可逆动作：
此操作将永久删除所有子账户→ 整句或核心动词（如永久删除）需strong - 法律条款中的责任锚点：
您同意即视为接受<code><strong>全部免责条款</strong>，不能只靠 CSS 加粗 - 避免整段包裹：
<strong>请仔细阅读以下说明...</strong>会稀释语义，辅助技术可能忽略
什么时候该用 em？看去掉后语气是否塌掉
原意还在，但少了反讽、惊讶、澄清、对比这些潜台词，就该用 em。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 表达意外或质疑：
我们“确实”支持 IE11—— “确实”带反语，不是事实重点 - 消除歧义：
这个按钮会删除数据，不是备份—— “不是备份”是语气转折点 - 口语化确认：
你真的确定要注销吗？—— “真的”是临时聚焦，非信息核心 - 别用
em包纯标点、空格或链接文字（如@#@#@#@#@#@#@#@#@#@0），读屏软件无法处理无语义内容
strong 和 em 能嵌套吗？能，但必须分层有理
混合不是为了视觉叠加（又粗又斜），而是外层定重要性、内层补语气。
- 合理嵌套：
<p>您<strong>必须</strong>在<strong>24 小时内</strong>完成认证</p>—— 外层强调义务，内层强调时限紧迫性 - 反例：
<strong>请勿尝试<em>破解系统</em></strong>—— “破解系统”才是风险核心，“尝试”不是语气焦点，嵌套错位 - 嵌套超过两层（如
<strong><em><strong>危险</strong></em></strong>）会让读屏软件困惑，实际极少需要 -
strong内部不要套em来强调副词（如<strong>请<em>立即</em>保存</strong>），除非上下文明确需要双重语义
为什么不能用 CSS 替代？因为语义不在样式里
你可以把 strong 设成 font-weight: normal，它仍是“重要内容”；把 em 设成加粗，它也不会变成“高优先级信息”。真正起作用的是 DOM 标签名本身。
- 屏幕阅读器对
strong通常加重停顿+提高音量；对em则改变语调（升调、拖长），行为完全不同 - 搜索引擎解析时，
strong内容可能获得更高关键词权重；em更倾向被识别为修饰短语 - 想纯样式控制？用
b或i—— 它们就是无语义的视觉开关，适合产品名、术语、外文短语等中性场景 - 测试盲区：开发很少真用读屏软件验证，但
strong嵌套、em包空格、strong套在button里，都是无障碍检测（axe/Lighthouse）高频报错点
