Webman不是CDN，仅能模拟简易反向代理+缓存；禁用file_get_contents回源，须用curl或ReactPHP异步客户端；需手动实现缓存逻辑、状态码透传与响应头设置。
Webman 本身不是 CDN，也不能替代 CDN 服务；它只是一个 PHP 的高性能 HTTP 服务框架。想用 Webman 实现“CDN 内容分发逻辑”，本质是模拟边缘节点的缓存代理行为——即：接收用户请求 → 查询本地缓存 → 缓存未命中则回源 → 缓存响应并返回。这属于简易反向代理 + 缓存层，不是真正意义上的 CDN（无全球节点、无智能调度、无 DNS 层路由）。但对开发测试、私有内网加速或轻量静态资源托管，确实可行。
Webman 中用 file_get_contents 回源会出问题吗？
会，而且很常见。直接用 file_get_contents 请求源站，容易卡住、超时、不带 Header、无法处理重定向，且无法复用连接。更严重的是：它不支持流式转发，大文件（如视频、ZIP）会把内存撑爆。
- 必须改用
curl或ReactPHP异步客户端（Webman 原生推荐后者） - 关键要设置
CURLOPT_TIMEOUT和CURLOPT_CONNECTTIMEOUT，否则一个慢源站拖垮整个服务 - 务必透传原始
User-Agent、Accept-Encoding等 Header，否则源站可能返回不兼容内容或拒绝请求 - 禁止用
file_get_contents('http://...')做代理逻辑，这是线上事故高发点
如何让 Webman 节点自动缓存静态资源？
核心是拦截请求路径、生成缓存 Key、读写本地文件系统（或 Redis），并正确设置响应头。Webman 没内置缓存中间件，得自己写。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 缓存 Key 建议用
md5($_SERVER['REQUEST_URI'] . $_SERVER['HTTP_ACCEPT_LANGUAGE'] . $_SERVER['HTTP_ACCEPT_ENCODING'])，避免语言/压缩差异导致缓存污染 - 缓存目录必须可写，且建议限定层级（如按前两位哈希分目录），防止单目录文件过多影响 inode 性能
- 响应中必须设置
Cache-Control: public, max-age=3600和ETag，否则浏览器和中间代理不会复用 - 对
.html这类可能动态的内容，不要盲目缓存；优先缓存.js、.css、.png等明确静态后缀
response()->withStatus() 能透传源站状态码吗？
不能直接透传。Webman 的 response()->withStatus() 只设当前响应的状态码，而源站返回的 404、302、503 等需要你主动捕获并还原。
- 用
curl时需开启CURLOPT_HEADER并解析响应头中的HTTP/1.1 404 Not Found行，再调用withStatus(404) - 对 301/302 重定向，别直接
header('Location: ...')，应判断是否允许跳转（避免循环或跨域泄露），再决定是跟随还是透传 - 源站返回的
Content-Type、Content-Length、Set-Cookie（谨慎！一般不应透传）都需手动提取并设置到当前 response - 特别注意：源站返回的
Transfer-Encoding: chunked无法直接用 file_put_contents 缓存，必须边收边存或转为 content-length
真要上生产，这类“自建 CDN 逻辑”只适合极低流量场景或内部工具链。一旦并发上来，磁盘 I/O、缓存淘汰、缓存一致性、HTTPS 卸载、TLS 版本协商等问题会集中爆发。真正的 CDN 是基础设施级服务，不是靠几个中间件拼出来的。
