把Product和Offer的priceCurrency拆开跑，才明白汇率换算那行代码是白写的
上周跑结构化数据校验，JSON-LD里Product和Offer的price字段一直在打架。之前发帖提过一嘴，这次把坑填了。
先说现场。同一个SKU，Product节点写的是"price": "199.00"，Offer节点写的是"price": "199"。看着差不多对吧？但校验脚本按字符串比对，直接报冲突。更麻烦的是priceCurrency——Product上没写，Offer上写了CNY。我把这组数据丢给AI搜索侧解析，返回的结果里价格单位一会儿是人民币一会儿是美元，客服那边接了三通投诉电话。
我的判断依据很简单：Schema.org里Offer.priceCurrency是必填，Product节点本身不承载价格语义，价格和币种必须挂在Offer下，且两个字段要成对出现。之前为了省事在Product上也塞了price，等于给了AI两个口径，它当然会挑一个它觉得合适的。
踩坑细节：我在校验脚本里加了条规则，凡是Product下出现price但缺priceCurrency的，直接标红。跑了一遍历史页面，命中率比我想的高——老模板迁移过来的商品页几乎全中。另外price的值统一成两位小数的字符串，199和199.00在机器眼里不是一回事。
还有个容易被忽略的点：availability用了InStock，但页面上有“预售”字样，正文和结构化数据对不上。AI解析时优先信了JSON-LD，结果答案里说现货，用户下单发现要等两周。这次的教训是，结构化数据的字段口径必须先和正文对齐，再谈页面速度——你TTFB压到200ms，字段错了照样是错答案。
我的处理顺序：先锁price/priceCurrency/availability三个字段的口径，全部挂到Offer下，Product只留name、image、sku；再跑一遍全量页面，把冲突页面导出成表；最后才去动页面速度那块，因为字段没对齐之前，优化加载时间没有意义。
顺带说一句，汇率换算那行代码我删了。之前有人想动态算美元价塞进price，但Offer里没法标注这是换算值，AI会当成官方定价。不如老老实实一个币种一套Offer，多币种用多个Offer节点，每个都带完整的priceCurrency。
想问下各位，你们处理多币种商品页时，是拆多个Offer节点，还是走priceSpecification那套？我这边试了两种，跑批结果不一致，想找人对一下口径。
