bug20251017
js的精度问题字面量
问题
- • 查询日志显示条件是 shop_id = 6435696815883747000 AND item_id = '852930494' ，返回总数 0。
- • 你贴出的库中记录 shop_id = 6435696815883747385 且 item_id = '852930494' ，两者 shop_id 不一致，导致匹配失败。
- • 代码定位： WlmListingService.relatedSku 使用 shopId 与优先级最高的 itemId 精确匹配（ shopId && itemId ），未命中直接抛出“未找到待更新的WLM Listing记录！”。
- • DTO 类型： WlmListingRelatedDto.shopId 是 Long 。前端如果用 JavaScript Number 直接传这种 19 位 ID，会发生精度丢失（超过 Number.MAX_SAFE_INTEGER ），JSON 序列化后数字已被“舍入”为 6435696815883747000 ，后端按 Long 接受，查询自然命不中。
修复
- • 前端修复（推荐）：把所有超出安全整数范围的 ID（如 shopId ）改为字符串传输，例如 "shopId": "6435696815883747385" 。后端 Jackson 能把数字字符串安全转换为 Long，避免 JS 端精度问题。
- • 后端健壮性增强：
- • 保持 DTO 字段为 Long 不变，但增加参数校验：拒绝不在安全整数范围内且末位为大量 0 的 Long（典型精度丢失特征），提示前端改为字符串传。
- • 或将 DTO 的 shopId 改为 String ，服务层显式 Long.parseLong(dto.getShopId()) 并捕获异常，明确错误信息。但这涉及接口签名变更，需评估影响。
- • 查询降级思路（不建议作为首选）：当 shopId && itemId 未命中时，自动用 shopId && msku 或 shopId && gtin 再试。此举会改变现有“itemId 优先且必填”的业务语义，需产品确认。
.preview-wrapper pre::before { position: absolute; top: 0; right: 0; color: #ccc; text-align: center; font-size: 0.8em; padding: 5px 10px 0; line-height: 15px; height: 15px; font-weight: 600; } .hljs.code__pre > .mac-sign { display: flex; } .code__pre { padding: 0 !important; } .hljs.code__pre code { display: -webkit-box; padding: 0.5em 1em 1em; overflow-x: auto; text-indent: 0; } h2 strong { color: inherit !important; }
本文使用 文章同步助手 同步
