应优先使用<strong>而非<b>，因<strong>承载语义重要性，影响辅助技术、SEO及自动化处理；<b>仅用于纯视觉突出且无语义权重的场景。
该用 <strong> 还是 <b>，不取决于“要不要加粗”，而取决于“这段文字是否承担语义责任”。
什么时候必须用 <strong> 而不是 <b>
当文本需要传达「强重要性」，且这种重要性会影响辅助技术、搜索引擎或自动化处理逻辑时，<strong> 是唯一合理选择：
- 表单校验失败提示，如
<strong>邮箱格式不正确</strong>—— 屏幕阅读器会加重语气朗读，用户能立刻感知风险 - 支付页金额数字，如
订单总额：<strong>¥299.00</strong>—— 语义上标定关键数值，避免被忽略 - 权限变更弹窗中的操作后果，如
<strong>删除后不可恢复</strong>—— 不是强调“这个词要醒目”，而是声明“这句话有不可逆的业务权重” - API 文档中标记必填参数，如
user_id: <strong>string</strong> (required)—— 工具链（如 OpenAPI 解析器）可能依赖该语义生成校验逻辑
什么时候可以用 <b>（且不宜用 <strong>）
<b> 的定位非常窄：纯视觉突出，无语义权重，也不暗示语气变化。它不是“弱化的 <strong>”，而是另一类用途：
- 文章摘要里的关键词，如
本文探讨了 <b>响应式布局</b> 与 <b>CSS 容器查询</b> 的协同机制 - 产品评测中多次出现的品牌名，如
<b>iPhone 16</b> 的 A18 芯片在多线程任务中表现稳定 - 命令行示例中的可执行命令，如
运行 <b>npm run build</b> 启动构建流程 - 导言（lede）首句中的核心名词，如
<b>零信任架构</b> 正在重塑企业安全边界
注意：<b> 不该出现在需要无障碍支持或 SEO 权重的上下文中；用错会导致读屏软件跳过、爬虫降权。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
<strong> 和 <b> 在 CSS 和可访问性上的实际差异
两者默认都加粗，但浏览器和辅助工具对它们的处理路径完全不同：
- CSS 中，
<strong>可通过font-weight改为细体、斜体甚至下划线，语义不变；<b>若被设为font-weight: normal，就彻底失去存在意义 - 读屏软件（NVDA / VoiceOver）对
<strong>默认提升音调或延长停顿；<b>则完全静默处理，等同于普通文本 - 搜索引擎仍会将
<strong>内容视为页面关键词锚点，尤其在标题、摘要、列表项中；<b>几乎不参与关键词权重计算 - HTML5 规范明确指出：
<b>仅用于“实用型突出（utilitarian emphasis）”，即帮助用户快速扫视定位信息，而非表达内容重要性
容易被忽略的细节：嵌套与可访问性陷阱
真实项目里最容易翻车的地方，往往藏在看似无害的嵌套和样式覆盖中：
- 不要把
<strong>当作“加粗工具”反复嵌套，如<strong><strong>错误提示</strong></strong>—— 多层<strong>不会叠加语义强度，反而可能干扰读屏节奏 - 避免用 CSS 强制重置
<strong>的字体粗细（如strong { font-weight: 400; }），这会让语义和呈现严重脱节，违反 WCAG 1.3.1 原则 - 在代码块（
<pre><code>）中加粗变量名时，优先用<strong>而非<b>，因为变量名本身承担角色语义（如const <strong>user</strong> = ...），不是单纯为了视觉分隔 -
<b>在 HTML5 中未被废弃，但规范要求：“只有在没有更合适的语义标签可用时”才使用它 —— 换句话说，先想<em>、<mark>、<dfn>，再考虑<b>
