yii不处理gzip压缩，需由nginx/apache完成；强行php层压缩易冲突且干扰流式响应；nginx需配置gzip on、min_length、comp_level、types（含application/json）、vary五项；排查时先验响应头content-encoding，再查yii是否误设头或绕过输出链路。
Yii本身不处理GZIP压缩，得靠Web服务器
Yii框架自身没有内置GZIP压缩逻辑——它只负责生成响应内容（比如JSON），而压缩动作必须由Nginx或Apache这类反向代理/HTTP服务器完成。强行在PHP层用ob_gzhandler或zlib.output_compression开启压缩，不仅效率低、易与Yii的输出缓冲冲突，还会干扰Content-Length头、导致流式响应异常。
- Spring Boot、Express等框架提供“应用层压缩开关”，但Yii不是这样设计的
- 所有现代浏览器在请求头中自动带
Accept-Encoding: gzip，只要Nginx配置正确，压缩就静默生效 - 验证是否生效，直接看响应头里有没有
Content-Encoding: gzip，而不是看Yii日志或返回体大小
Nginx配置GZIP的关键5项不能漏
把GZIP配置写在http块里最稳妥，避免在server或location里重复或覆盖。以下五项是实际线上跑得稳的最小安全集：
-
gzip on：必须显式打开，Nginx默认是off -
gzip_min_length 1024：小于1KB的响应不压，否则压缩开销反而大于收益（比如一个{"code":0}） -
gzip_comp_level 5：别设9，CPU飙升且压缩率提升微乎其微；4–6是实测平衡点 -
gzip_types application/json text/plain text/css application/javascript：务必包含application/json，这是Yii API返回的主力MIME类型；别加image/*或font/*，徒增CPU负担 -
gzip_vary on：让CDN或代理知道“同一URL可能返回不同编码”，避免缓存错乱
为什么Yii接口没被压缩？先查这三处
常见现象：Nginx配置写了，curl -I看首页有Content-Encoding: gzip，但调/api/v1/users却没压缩——大概率不是Nginx问题，而是路由或响应头干扰了。
- 检查Yii是否手动设置了
Content-Encoding头（比如在beforeAction里误写Header::set('Content-Encoding', 'identity')） - 确认API action没调用
Response::setStream()或sendContentAsFile()，这些会绕过Nginx压缩链路 - 用
curl -H "Accept-Encoding: gzip" -I http://yoursite/api/v1/users直连Nginx，排除前端代理（如Cloudflare）中间解压再发裸体响应
性能影响和兼容性底线
GZIP对Yii JSON接口效果极明显：一个300KB的用户列表响应，通常能压到80–100KB，首字节延迟（TTFB）几乎不变，但整体传输时间下降60%+。但要注意两个硬限制：
- HTTPS下启用GZIP需警惕BREACH攻击——不过只要Yii不把敏感信息（如CSRF Token、密码错误提示）直接塞进JSON响应体，风险可控；Nginx 1.19+已默认规避部分场景
- 移动端弱网用户受益最大，但老旧Android 4.x WebView（未打补丁）可能解压失败；若必须兼容，可加
gzip_disable "msie6"（虽IE6早死，但某些WebView UA伪装成它）
真正容易被忽略的是：Nginx的gzip_buffers默认值太小，高并发下可能触发gzip buffer exhausted警告，建议明确设为gzip_buffers 16 8k——这事不报错，但压缩会悄悄降级失效。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
