如果询价接口把收到的买家币种写进一个全局对象，然后等待产品资料返回，等待期间另一条请求就可能改动同一个对象。第一条请求恢复执行时，若继续读取这个全局值，取到的可能是另一位买家的币种。问题不一定出在价格计算，而可能出在参数保存的位置。

AWS于10月12日介绍Lambda Web Functions，支持标准HTTP应用，并允许同一执行环境同时处理多个请求。对于已经在评估这类Node.js部署方式的团队，值得检查的是请求之间是否共享了不该共享的可变状态。没有自建询价程序的企业，不需要因为这条消息重新做一套系统。

一次只运行一段代码，不等于只有一条请求

Node.js中的异步等待，会让一条尚未完成的请求把执行机会交给其他工作。数据库读取、外部接口调用或文件操作期间，其他请求可以向前推进。因此，即使某段JavaScript不是同时执行，多个请求的处理过程仍可能交错，先写入的全局值也可能在等待期间被覆盖。

买家编号、选定型号、数量、币种和适用的报价条件，属于这条请求的上下文。它们应随请求参数、局部变量或明确的请求作用域传递。后续计算使用自己收到的那份值，不要临时去读“当前买家”或“当前币种”这样的共享对象。

共享变量并非一概不能使用。只读的产品字段定义、经过版本标记的公共配置，可能适合复用。需要警惕的是把“方便复用”扩展成“所有请求都写这里”。缓存也要区分公共内容与买家专属内容；仅按产品型号缓存一份含买家条件的结果，仍可能把不同请求混在一起。

把交错发生的过程测出来

检查可以从一条实际处理路径开始：收参数、等资料、算结果、回响应。圈出等待前后会读写的共享对象，再看其中有没有买家专属字段。若只在本地依次发送请求，所有结果正确，也不能排除交错执行时的问题。

更有针对性的测试，是用不含真实客户资料的不同参数，让请求在同一时段进入，分别核对响应中的型号、币种与输入是否对应。测试应有明确的请求标识，便于把每份输出对应回输入；无需通过大量无界请求去冲击线上服务，也不要为方便调试记录敏感报价内容。

若发现结果串用，先区分数据到底在哪一步改变。询盘故障保留不同解释再验证适用于这类排查：共享内存覆盖、缓存键不完整、下游返回错误，都可能造成相似表象。看到币种不对，不足以直接认定某一个原因。

请求完成以后仍需保留的报价草稿或操作状态，也不宜只依赖进程内存。执行环境是否继续存在、下一次请求是否进入同一环境，都不应成为业务数据能否找回的前提。持久保存与请求内隔离解决的是两个问题，修好其中一个不能替代另一个。

AWS这项能力有其运行时与区域条件，是否采用仍需单独评估。但只要一个HTTP进程可能交错处理多条业务，请求参数就不该靠一个不断变化的“当前值”来传递。先守住这条边界，再谈部署形式。

参考来源