北京
在Laravel项目的性能优化中，我们尝试过调整OPcache参数、修复慢查询、引入Redis片段缓存、把任务卸载到队列——但所有这些手段加在一起，都不如全页HTML边缘缓存带来的提升明显。前者的每一项都只是在缩短请求的处理时间，可请求依然要到达源服务器，依然要启动框架、渲染视图。而边缘缓存直接把请求拦在了门外：访客从距离自己最近的Cloudflare节点拿到已经渲染好的完整HTML，延迟只有几毫秒，你的服务器甚至根本不知道这次访问发生过。
奇怪的是，几乎没有人愿意为Laravel启用这项能力。原因并不复杂：Laravel几乎在每个Web请求中都会操作session，并在响应中返回Set-Cookie头。任何行为规范的共享缓存，都拒绝存储携带Set-Cookie的响应。于是大多数团队只能缓存图片和JavaScript，所有HTML响应都被标记为DYNAMIC，然后继续困惑为什么海外用户的TTFB仍高达600毫秒。本文要分享的，就是我们在web-pioneer.com生产环境中解决这个问题的完整方案，包括一路上踩过的坑。
整个架构只围绕一个设计决策展开：缓存逻辑放在Laravel应用里，而不是放在Cloudflare控制台。Cloudflare的职责被简化成一条死命令——“只有当源站允许缓存HTML时，才缓存”。源站是一个名为EdgeCache的小型中间件，只有它知道某个响应能否安全地共享给不同访客。当响应允许共享时，中间件输出Cache-Control: public, s-maxage=600；不允许时，则输出no-cache。
这个方案之所以稳健，靠的是两个特性。第一，默认拒绝。所有响应默认都不可缓存，除非通过明确的白名单校验：匿名访问、GET请求、HTTP 200状态码、HTML内容类型。任何新路由、错误页面、登录后的区域，全部按失败安全模式处理。第二，单一事实来源。缓存规则随代码库一起发布，经过代码评审，并有自动化测试覆盖。没有人需要记得Cloudflare后台里还有一个开关，暂存环境的缓存行为也与生产环境完全一致。
这套设计让“边缘只执行、应用做决策”成为可能。相比在CDN面板里手工配置规则，它更易维护、更可预测，也更容易在团队协作中保持一致性。对于饱受跨地域访问延迟困扰的Laravel项目，这是一个值得认真考虑的架构方向。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
