直接控制p标签内嵌套元素字体需用后代选择器精准干预，因strong、em等有浏览器默认font-weight/font-size，仅设p的font-family无效；应分别设置p strong、p a、p code等规则，并避免盲目使用p > *。
直接控制 p 标签内嵌套元素的字体效果，靠的是 CSS 继承与选择器精度，不是给 p 本身设个 font-family 就万事大吉——子元素（如 strong、em、a、code）可能自带浏览器默认样式或用户代理规则，会覆盖继承值。
为什么给 p 设了字体，strong 还是加粗得不像样？
因为 strong 等语义化行内元素有浏览器内置的 font-weight: bold，而你只改了 p 的 font-family，没碰 font-weight。它继承了字体族，但“加粗”行为仍由自身规则触发。
- 浏览器对
strong、em、small等都有默认font-weight或font-size声明，优先级高于单纯继承 -
a标签还带color: blue和下划线，不重置就会和正文风格割裂 -
code默认用等宽字体（如monospace），即使p设了'PingFang SC'，它也不买账 - 解决办法不是禁止嵌套，而是用后代选择器精准干预：
p strong { font-weight: 600; }p a { color: inherit; text-decoration: underline dotted; }p code { font-family: 'SF Mono', Consolas, monospace; font-size: 0.95em; }
p > * 能不能一键重置所有子元素字体？
不能盲目用 p > *，它会命中 img、button、input 等非文本元素，导致意外缩放或错位；更危险的是，它会把 br、wbr 这类空元素也纳入样式作用域，虽无视觉影响，但违反语义直觉。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 真正安全的范围是仅针对**文本级元素**：
p em, p strong, p small, p a, p code, p abbr, p time - 避免用通配符重置
font-size：比如p > * { font-size: 1rem; }会让small失去缩小语义 - 若需统一字号，推荐用
inherit或1em，而非固定像素——保证响应式缩放时比例稳定 - 注意
button在p内是合法的，但它有自己完整的 UA 样式，p button选择器必须显式覆盖font相关属性才能生效
中英文混排时，code 和 em 的字体怎么不打架？
关键在 font-family 的 fallback 链设计。中文系统下，code 必须优先选等宽中文字体（如 'Fira Code CN'），而 em 应沿用正文字体并仅调 font-style ——二者不能共用同一字体栈，否则西文代码显示模糊，中文强调又缺笔画。
立即学习“前端免费学习笔记（深入）”；
-
p code推荐栈：font-family: 'JetBrains Mono', 'Cascadia Code', 'Fira Code', 'SFMono-Regular', monospace;
-
p em推荐写法：font-style: italic; font-family: inherit;
（不换字体，只倾斜） - 如果用了变量字体（如
font-variation-settings: 'wght' 500;），确保em不继承font-variation-settings，否则斜体+可变字重易发虚 - 旧版 Safari 对
font-feature-settings在em中的支持不稳定，如需开启连字（liga），建议只在p级启用，子元素不额外干预
最常被忽略的一点：字体效果是否生效，取决于元素是否真的“渲染为文本内容”。p 里塞了个 div，哪怕你写了 p div { font-family: ... }，DOM 已被浏览器自动修正为 p 关闭 + div 独立存在，样式规则根本不会匹配——所以检查字体前，先看开发者工具里元素真实结构。
