<strong>、<em>等是语义标签，用于表达文本含义而非代码格式化；真正提升HTML可读性的是结构化排版、语义化标签和编辑器自动化。
HTML格式化标签本身不提升代码可读性，真正起作用的是结构化排版、语义化标签和编辑器自动化——别把 <strong> 和代码格式混为一谈。
为什么<strong>、<em>这类标签不是“格式化代码”的工具
它们是内容级语义标签，作用对象是文本含义，不是源码视觉。你在编辑器里写 <p>价格<del>>，这行 HTML 的可读性取决于缩进、换行、空行是否合理，而不是 <code><del> 本身有多“清晰”。
- 浏览器渲染时忽略多余空白，但人靠缩进识别嵌套——
<section>没缩进，<h2>看起来像在<header>里，其实可能漏了闭合 -
<strong>和<b>功能相似，但语义不同；用错不会报错，却会让屏幕阅读器误读重点 - 手动加空格/换行不可持续，协作中一人改三行，缩进立刻崩坏
VS Code + Prettier 怎么真正自动做对缩进和换行
靠人盯不如靠配置。关键不是“要不要格式化”，而是让编辑器在保存时强制执行统一规则。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 启用
editor.formatOnSave，再设html.format.wrapLineLength为 120，防止单行过长 - 必须开启
html.format.indentInnerHtml: true，否则<div><p>文本</p></div>不会自动缩进子元素 - 禁用
html.format.unformatted里的pre（保留<pre>原始空格），但别加div或p——那会破坏所有块级缩进 - 配合
prettier插件，而非仅用 VS Code 内置 formatter，后者对属性排序、自闭合标签处理更弱
哪些地方缩进错位最常导致逻辑误判
不是语法错误，而是人看错了结构。这类问题调试时几乎不报错，但行为异常。
立即学习“前端免费学习笔记（深入）”；
-
<main>缺失或重复：多个<main>会让辅助技术只读第一个，SEO 可能降权 -
<nav>里塞了<form>或<button onclick>：语义断裂，aria-label很难补救 -
<section>没配<h2>：它就不是语义上的“节”，而只是视觉分组，RSS 抓取、大纲生成全失效 -
<img>忘写alt或留空：htmlhint 不报错，但 axe 扫描直接标红“accessibility violation”
最易被忽略的点：格式化不是终点，而是起点。你配好了 Prettier，但 <div class="card"> 还在那儿，没人知道它是商品卡片还是广告位——这时候类名、注释、语义标签的选择，才真正决定别人能不能 5 秒内看懂这段 HTML 是干什么的。
