span默认display: inline，不换行并排显示；div默认display: block，独占一行上下堆叠，核心差异在于是否破坏文本流及对盒子模型属性的支持程度。
span 和 div 的默认 display 行为差异
最直接的区别是浏览器对它们的默认渲染方式：span 默认是 display: inline，div 默认是 display: block。这意味着写两个 span 在同一行里，它们会并排显示；而两个 div 会自动换行、上下堆叠。
这个差异不是“能不能加样式”的问题，而是“加了样式后是否破坏文本流”的问题。比如在一段文字中插入一个容器想高亮某个词，用 div 会导致整段文字断开、换行，用 span 则自然融入。
- 误用
div包裹单个词：页面出现意外空行或布局塌陷 - 误用
span包裹整个导航栏：CSS 的width、margin-top等属性可能无效或表现异常 - 可通过
display: inline-block或display: flex手动调整，但应先确认是否真需要绕过语义和默认行为
嵌套内容限制与 HTML 合法性
span 在 HTML 规范中只能包含“phrasing content”——也就是文本、a、em、img（带 alt）、input（type=text）等内联级元素。它不能直接包 p、div、ul 这类块级元素。
而 div 没有这类限制，可自由嵌套任意合法子元素。浏览器遇到非法嵌套（如 span 里写了 div）通常会自动修复 DOM，但修复逻辑不统一，可能引发样式错位或 JS 获取节点失败。
立即学习“前端免费学习笔记（深入）”；
- 检查控制台是否报
HTML validation warning类提示，尤其在 SSR 或静态生成场景下更敏感 - 用浏览器开发者工具查看 Elements 面板，观察实际生成的 DOM 结构是否与预期一致
- 若需包裹混合内容又想保持语义，优先考虑
section、article、nav等语义化标签，而非强行用div或span
样式控制能力的实际边界
div 可以完整使用盒子模型：width、height、margin（含上下）、padding（含上下）、border 全部生效；span 的 margin-top/margin-bottom 和 padding-top/padding-bottom 在纯 inline 模式下不推挤相邻行，只影响行高视觉，容易造成“设置了但没反应”的错觉。
这不是 bug，是 CSS 规范对 inline 元素的定义。想让 span 响应垂直方向尺寸，必须显式改 display（如 inline-block、inline-flex），但这已脱离其原始设计意图。
- 给
span加background-color是安全的，它会紧贴文字内容铺开 - 用
span实现“按钮式标签”时，务必加display: inline-block，否则padding上下可能被截断 - 避免对
span设置height：它不会撑开容器，反而可能剪裁文字
何时该放弃 span/div，转用语义化标签
现代 HTML5 中，div 和 span 是“无语义通用容器”，仅当没有更贴切的语义标签可用时才用。比如导航栏不该写成 <div class="nav">，而应是 <nav>；页脚不是 <div id="footer">，而是 <footer>；强调一段话不用 <span class="highlight">，而用 <mark>。
语义标签不只是“看起来更规范”，它直接影响屏幕阅读器行为、SEO 权重分配、甚至浏览器原生功能（如 <details><summary> 自带展开逻辑）。用 div 或 span 强行模拟这些行为，等于自己实现一套不兼容、不可访问的 UI。
- 检查 W3C HTML validator 输出，关注 “Element X is obsolete” 或 “Consider using a more semantic element” 类提示
- 用 Chrome 的 Lighthouse 工具跑 Accessibility 审计，语义缺失会直接扣分
- 团队协作中，
div和span的泛滥往往意味着语义意识薄弱，后续维护成本会上升
真正难的不是记住“span 是行内、div 是块级”，而是在嵌套层级变深、CSS 越来越复杂时，还能一眼判断：这里到底该用语义标签、div、还是 span——尤其是当设计师给的稿子里全是“视觉区块”，而你得决定哪个该是 section、哪个只是 span 包裹的修饰词。
