Google要求Review必须嵌套在Product或LocalBusiness等父类型下，review字段须为数组，reviewRating必须是含@type、ratingValue的Rating对象，reviewBody和author需符合纯文本与结构化格式规范。
Google 目前不支持独立的 Review 类型作为顶层结构化数据——直接写 "@type": "Review" 会失效，必须嵌套在 ItemPage、Product 或 LocalBusiness 等支持评价的父类型下。
Review 必须依附于被评价对象，不能单独存在
Google 的富媒体搜索结果只认可“某物的评价”，而不是“一条评价”。比如你有一条用户对某款耳机的评论，Review 必须作为 Product 的 review 字段值出现，或作为 LocalBusiness 的 review 字段值；否则 Rich Results Test 会提示“未检测到有效评价”。
-
Product类型下用review字段（数组），每个元素是Review对象 -
LocalBusiness类型下也用review字段，且要求至少含author、datePublished、reviewBody和reviewRating - 别把
Review当作页面主类型塞进script块顶层——这属于常见无效写法
reviewRating 必须是对象，不是数字或字符串
很多人把评分写成 "reviewRating": 4.5 或 "reviewRating": "4.5"，这会导致整个结构化数据被忽略。Google 要求 reviewRating 是一个完整对象，且必须含 @type 和 ratingValue，推荐补全 bestRating（通常为 5）。
- 正确写法：
"reviewRating": { "@type": "Rating", "ratingValue": "4.5", "bestRating": "5" } -
ratingValue可以是字符串（如"4.5"），但不能是浮点数字面量（JSON 不允许尾随小数点后无数字，如4.） - 如果只有整数评分（如 4 星），仍需写成字符串
"4"或数字4，但必须包裹在Rating对象里
reviewBody 和 author 的文本要求很严格
reviewBody 必须是纯文本，不能含 HTML 标签；author 若为个人，必须是对象（含 @type: "Person" 和 name），不能只写字符串。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 错误示例：
"reviewBody": "<p>音质很棒！</p>"→ 引号和<p></p>未转义，JSON 解析失败 - 安全做法：从 DOM 提取
textContent，再用JSON.stringify()序列化，自动处理换行与引号 -
"author": "张三"会被忽略；必须写成"author": { "@type": "Person", "name": "张三" } - 如果作者是机构，
@type得设为"Organization"，并提供name
多个评价共存时，review 字段必须是数组
哪怕只有一条评论，review 字段也必须是数组（[]），不能是单个对象。这是 Schema.org 规范强制要求，也是 Google 解析的前提。
- 正确：
"review": [{ "@type": "Review", ... }] - 错误：
"review": { "@type": "Review", ... }→ Rich Results Test 直接报“缺少 review 数组” - 多个评价就往数组里 push，别合并字段或去重——每条评论都应独立存在
- 注意数组长度上限：Google 对单页
review数量无硬性限制，但建议控制在 10 条以内，避免 JSON 过大影响首屏加载（虽不阻塞渲染，但冗余数据无益）
最容易被忽略的是 review 字段的数组包装和 reviewRating 的对象结构——这两处出错，整段标记就等于没写。上线前务必用 URL Inspection Tool 粘贴完整 HTML 源码验证，别只看编辑器高亮是否正常。
