、等是语义标签,用于表达文本含义而非代码格式化;真正提升html可读性的是结构化排版、语义化标签和编辑器自动化。

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










