microformat是一套基于class等属性的公开语义约定，本质是向外部工具承诺结构契约，因此h-card比user-profile更难维护。
microformat 不是 HTML 原生语法，它是一套基于现有属性（主要是 class、rel、property）的语义约定。想靠它提升可维护性，关键不在“加不加”，而在“怎么加才不反噬项目”。
为什么 class="h-card" 比 class="user-profile" 更难维护
微格式名（如 h-card、h-event、u-url）本质是公开协议，不是内部命名空间。一旦写进 HTML，就等于向外部工具（解析器、爬虫、浏览器扩展）承诺了结构契约——你改了 class 名，第三方工具就失效；你改了嵌套顺序，p-name 可能被误读为组织名而非人名。
而 user-profile 是封闭语义，只服务本项目 CSS/JS，改名、重构、抽离组件都不影响外部。可维护性第一要义是「控制力」，微格式恰恰把部分控制权让渡给了外部生态。
- 微格式类名不能加前缀（如
my-h-card），否则解析器不识别 - 不允许混用：不能同时用
h-card和自定义 BEM 类（如card__header）在同一个元素上表达同一层语义，否则结构歧义 - 必须严格遵循官方文档的属性位置（例如
tel必须在a[href^="tel:"]内，不能塞进span）
哪些场景真需要 microformat，而不是语义化标签 + data-*
只有当你的 HTML 明确要被机器消费时，才值得引入微格式。典型场景包括：
立即学习“前端免费学习笔记（深入）”；
- 企业官网联系页需被 Outlook / Apple Contacts 一键导入（用
h-card） - 活动页面需被日历应用识别并添加事件（用
h-event） - 博客文章需支持 RSS 解析器提取作者、发布时间（用
h-entry）
其他情况，优先用原生语义标签（<time datetime></time>、<address></address>）或带项目前缀的 data- 属性（如 data-user-id）。它们不承担协议义务，改起来无副作用。
如果必须用 microformat，怎么降低维护成本
核心策略是「隔离」与「验证」：
- 只在明确对外暴露的模板片段中使用（如
contact.html、event-listing.html），禁止在通用组件（header.html、card.html）里硬编码h-*类 - 所有微格式类名必须和对应 schema.org 类型对齐（
h-card↔Person或Organization），避免语义漂移 - 每次修改后用 W3C Markup Validator + Schema Markup Validator 双校验，重点看「Microdata / RDFa / Microformats」解析结果是否符合预期
- 禁止用 JS 动态注入微格式类名——解析器只读取初始 HTML，JS 添加的
h-*类无效
微格式不是“更高级的语义”，而是“有代价的语义”。它省掉的是机器解析成本，但抬高了人工维护门槛。真正容易被忽略的点是：你写的每一个 h-card，都在替未来某天的自己签一份不可撤销的结构契约。
