产品图片适合重复分发，专属报价却可能因买家、币种和有效期而不同。把两者接到同一个CDN，不代表应给它们同一种缓存策略。只要响应包含特定买家的条件，就要先说明谁能读取，再决定它能不能被其他请求复用。

AWS于10月12日宣布CloudFront支持以Lambda Web Functions作为源站，提供边缘缓存等能力，并通过OAC限制源站只能经由CloudFront访问。公告同时说明，已有应用仍可自行认证用户。两句话对应不同边界：限制直连源站，并没有替应用识别眼前是哪位买家。

源站被保护，不等于报价按人隔离

OAC处理的是CloudFront到源站的访问路径。买家登录、报价归属和业务权限，仍需应用判断。即使请求合法经过CDN，也不能因此把一份报价返回给任何访问者；知道报价编号同样不能替代读取资格。

缓存又是另一层决定。它根据配置中的缓存键判断哪些请求可以使用已有响应。如果应用按买家身份生成内容，但缓存键没有表达相应差异，共用响应就可能与应用原本的区分相冲突。不能仅看源站代码逐次认证正确，就认为每个边缘命中的请求都会重新执行同样判断。

对于外贸企业的网站负责人，最简单的内容划分是：公开型号介绍与通用图片单独加速；包含买家专属价格、折扣、项目说明或账户资料的响应，默认不进入共享缓存。确需缓存的复杂场景，应由维护方证明隔离方案，而不是把身份参数全部塞进网址。

写了private，还要看实际缓存策略

CloudFront当前文档说明，CachingOptimized策略不把Cookie和查询字符串纳入缓存键，且最小TTL大于零。文档特别提醒，这种最小TTL会让内容至少缓存相应时间，即使源站返回no-cache、no-store或private指令。

所以，“程序已经写了不缓存”不是完整答案。还要检查具体路径挂的是哪种缓存策略、最小TTL是多少，以及源站请求策略实际转发了哪些身份信息。不能只凭策略名称里有Optimized，就把它当成适用于所有网站响应的默认选项。

对于不应缓存的动态路径，官方提供CachingDisabled策略，相关TTL均为零。选择它并不能替代买家认证，却可以避免把这类响应作为共享副本复用。公开静态文件仍可保留自己的缓存安排，不需要为了保护报价而关闭整站加速。

用两种身份检查，不只看一次页面正常

验收应使用获准的测试账户和非真实敏感报价，先由一个账户访问，再由另一个账户请求同一路径，随后交换访问顺序。观察第二位用户看到的是自己的结果、明确的拒绝，还是上一位的内容。只测试第一次没有缓存的访问，可能看不出复用问题；退出登录和报价过期后的返回也要检查。

还要注意，应用进程与CDN是不同的复用位置。请求内买家参数的隔离处理可变全局状态；这里处理已经生成的响应能否被边缘复用。修好其中一层，不会自动修好另一层。

这项工作不需要先追求最高缓存命中率。对专属报价，正确返回或正确拒绝比共享副本更多更重要。先把公开内容与按人生成的内容分开，再讨论加速范围，才能避免把访问控制问题藏进性能指标里。

参考来源