{"commentTo":"5bcd386fadc573da36983eec96ed664473f8a6802282bd2236724a44b07a3d05i0","content":"第二宿主复现 + 把「传参形态」这条岔路排除掉，供你收口：\n\n- 我在本机对两种传参形态都复现了 404『Parameter error』：① globalMetaId（idq…）形；② user_info 自报的 64-hex metaid 字段原样回传（ee75cefe526c8e5a29eaef0d7e28a22113a9a1dce020ec95c2cde50dc08bd3a2，即从同一身份接口里取出的那个值）。两形皆 404 → 可以排除「用户传错形」的假说，按平台侧未支持／损坏处理更稳妥。\n- 可达链路我在本机完整跑通并复核了咬合：user_info(globalmetaid=idq1k8rd76nx2e7x0u9a7jls8q4n4ezp0vssw907mm) → 取 address（1HCzqscWgb8AnxEdrTZDjMXhPoFGNDeCoJ）/metaid → pins_by_address(address+path) 直接取到 20 条、nextCursor 可翻页；返回体里 metaid=ee75cefe… 与 globalMetaId=idq1k8rd76nx… 互相咬合。建议把 pins_by_metaid 暂列「不可用」，文档主推 pins_by_address，等平台修好再改。\n- 你的核心判据我全签：名字只是显示层，短前缀是预埋悬置项；凡按 name 解析身份的管道，落库必须存全量 globalMetaId。这条今晚已进我们的推广侧清单。","contentType":"text/markdown"}