微格式不是简单添加class，而是复用html语义标签并按约定命名class；必须将h-card等类名嵌套在、等语义元素内，配合p-name、dt-published等子类使用，否则机器无法解析。
微格式不是加 class，而是复用已有语义标签
很多人把 class="h-card" 往 <div> 上一塞就以为用了微格式，结果只是给机器扔了个无法解析的字符串。微格式（如 <code>h-card、h-entry、h-event）本质是**在标准 HTML 语义结构上叠加约定好的 class 命名规则**，它不创造新标签，也不改变 DOM 结构——它依赖你 already 用对了 @#@#@#@#@#@#@#@#@#@0 也支持 h-*）
<li>电商商品页需暴露价格、库存、SKU 等多维属性 → microdata 或 JSON-LD 更稳妥，<code>itemprop="price" 比 data-price 更易被 Google Shopping 抓取
容易踩的坑：
- 在一个元素上同时写
class="h-card"和itemscope itemtype="https://schema.org/Person"→ 解析器可能冲突或忽略其中一种 - microdata 中
itemprop值直接写文字（如<span itemprop="name">张三</span>），但未包裹在itemscope容器内 → 数据丢失 - 用 RDFa 的
property属性时漏写typeof，导致结构化数据不可识别
验证不是“有没有 class”，而是“能否被提取”
写完微格式，不能只靠肉眼检查 class 名是否拼对。真实检验标准是：机器能否从中稳定抽取出结构化字段。Google Rich Results Test 工具常报“未检测到结构化数据”，往往不是 class 错，而是父级语义缺失或嵌套错位。
实操建议：
- 用浏览器 DevTools 的「Elements」面板，右键目标元素 →「Reveal in Elements panel」→ 查看其完整祖先链：是否从
<article></article>开始？是否有<time></time>同级或子级？ - 运行
npx html-validate --config ./html-validate.json（配html-validate-plugin-microformats插件），它会检查h-card是否缺p-name、h-entry是否缺dt-published - 在 Chrome 中安装插件 «Microdata Inspector»，悬停元素即可看到实时解析出的字段名和值 —— 如果显示
name: null，说明p-name所在节点没被正确识别为文本内容容器
可维护性陷阱：微格式 class 不是样式锚点
把 class="p-name" 当成 CSS 选择器来写样式，等于把语义逻辑和表现层耦合死。一旦设计改版要换字体大小或颜色，你得同步改 JS 查询逻辑、CSS、甚至微格式校验规则。
正确做法：
- CSS 用独立 class 控制样式，比如
class="author-name"，而非依赖p-name - JS 查询结构化数据时，用
document.querySelector('article .p-name')，但不要用document.querySelector('.p-name')—— 后者可能命中评论区里的昵称 - 服务端渲染时，确保
p-name总是出现在h-card的第一层子元素中，避免因 CMS 模板插入额外 wrapper 导致解析失败 - 团队协作时，在组件文档里明确标注：“该卡片组件输出符合 h-card 规范，要求传入
name、url、photo字段，且photo必须渲染为<img>”
最常被忽略的一点：微格式的生命力不在 class 名本身，而在它所依附的语义骨架是否稳固。如果 <article></article> 被误用为广告位，那再标准的 h-entry 也会被搜索引擎降权处理——结构错了，修饰再准也没用。
