p标签禁止嵌套div等块级元素，因html规范限定其仅能包含内联内容，否则浏览器自动修复导致结构错乱，影响响应式布局与可访问性。
为什么不能在 p 标签里嵌套 div 或其他块级元素
浏览器会自动“修复”这种非法嵌套，实际渲染时把闭合标签提前插入，导致结构错乱——比如你写 <p></p>
<div>内容</div>
<p></p>
<div>内容</div>
<p></p>。这不是兼容性问题，是 HTML 规范强制要求：p 只能包含内联内容（span、strong、a、文本等），不能含 div、h2、ul 或另一个 p。
响应式页面中一旦出现这种嵌套，CSS 的 max-width、flex 或媒体查询可能作用在“意外生成”的空 p 上，造成空白行、错位或断点失效。
- 检查控制台 Elements 面板，看是否出现未预期的自动闭合
- 用
aria-label或role="region"替代语义缺失的div嵌套需求 - 真要包裹多类型内容？改用
section或带role="paragraph"的div，再配合适当的可访问性属性
p 标签在 Flex/Grid 布局中如何保持换行语义不丢失
把多个 p 放进 display: flex 容器时，它们默认变成“行内块”，不再自动换行——但段落语义没变，只是视觉上并排了。这时候若没加 flex-wrap: wrap，小屏下会溢出或触发横向滚动条。
更隐蔽的问题是：p 的 margin 在 Flex 中仍生效，但上下外边距可能被折叠（尤其是相邻 p 之间），导致行间距忽大忽小，响应式断点切换时视觉跳变。
- 统一用
gap替代margin控制段落间距（flex或grid容器下更可靠） - 给
p设margin: 0，再由父容器用gap: 1rem统一管理，避免 margin collapse 干扰 - 需要单个
p换行？加flex-basis: 100%或align-self: flex-start强制独占一行
移动端小屏下 p 文字过小或撑破容器的常见原因
不是字体设得不够大，而是 viewport 元标签写错或缺失，或者用了固定 px 字号。比如 font-size: 14px 在 iPhone SE 屏上实际物理尺寸极小，而 width: 300px 的容器又没配合 max-width: 100%，导致文字被强行压缩、换行异常。
另一个典型现象：iOS Safari 对 p 内部的 em、rem 计算有细微偏差，尤其嵌套多层时，line-height 可能累积失真，造成行高塌陷或重叠。
- 优先用
rem+ 根字体动态缩放（如html { font-size: clamp(14px, 2.5vw, 18px); }） - 禁用
p的line-height继承，显式设为无单位数值（如line-height: 1.6） - 避免在
p上直接设width或min-width，它本就不该管宽度——交给父容器的max-width和padding
用 CSS 把多个 p 排成一行时必须注意的可访问性陷阱
用 display: inline 或 inline-block 强行让 p 并排，对屏幕阅读器来说仍是“多个独立段落”，但视觉上已失去段落分隔，容易误读为连续长句。更麻烦的是，键盘焦点无法自然跳转到每个 p（因为它们不是可聚焦元素），也无法用 Tab 导航到其中的链接或按钮。
如果业务逻辑确实要求“同一逻辑组内多个短段落横排显示”（比如产品卖点列表），就不能只靠 CSS 魔改 p 的 display，而应重构语义：
- 改用
ul+li，每个li包一个p，再用 CSS 控制布局（li天然可聚焦、可导航） - 保留
p，但加tabindex="0"和role="group"，同时用aria-labelledby关联标题 - 绝对不要用
float实现横排——它已废弃，且与现代响应式流式布局冲突严重
真正难处理的从来不是怎么让 p 并排或换行，而是当它和 flex、grid、media query、可访问性要求同时出现时，哪一层规则在悄悄覆盖哪一层语义。每次改样式前，先看一眼 Elements 面板里的实际 DOM 结构，比查文档更快定位问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
