yii\rest\ActiveController默认实现中GET与HEAD请求的区别

你观测到的结果完全符合Yii2框架的设计逻辑，也完全匹配HTTP协议对HEAD方法的标准定义。
你写的最简ActiveController默认就已经实现了HEAD方法的适配，不需要额外写任何业务代码：框架处理HEAD请求时，会完整执行和对应GET请求完全一致的流程——包括路由解析、权限校验、模型查询、分页参数计算、响应头生成，只是在最终响应输出阶段直接清空响应体，不会返回序列化后的实体内容，这就是你看到HEAD请求无响应体的原因。
至于GET请求额外携带Content-Length头也属于正常表现：因为HEAD请求不返回响应体，Yii2不会主动计算body长度生成对应字段，部分Web服务器可能会自动给HEAD响应补Content-Length: 0，但这属于服务器层配置，和Yii框架本身无关，不影响功能正确性。

HEAD方法的核心优势是在不传输响应体的前提下，获取和GET请求完全一致的响应头信息，用极低的网络传输成本拿到资源元数据，常见的落地场景包括：

• 接口存活监控：运维/监控系统定时探测接口可用性时，不需要拉取接口返回的全量业务数据，只需要发HEAD请求检查响应状态码是否为200即可，能大幅降低监控请求带来的带宽消耗、序列化性能开销。
• 资源存在性校验：比如需要确认ID为2的用户是否存在，不需要拉取该用户的全部字段信息，发HEAD请求到对应路径，返回200即存在、返回404即不存在，比GET请求省流量。
• 缓存有效性判断：客户端可以通过HEAD请求拿到Last-Modified、ETag等缓存校验字段，和本地缓存的对应值做对比，不需要拉取完整资源就能判断本地缓存是否过期，再决定是否发起GET请求更新缓存，尤其适合移动端等流量敏感场景。
• 大体积资源预检：如果接口可能返回大分页结果、大文件附件，客户端可以先发HEAD请求读取Content-Length头判断资源体积，提前给用户提示、或者判断是否在当前网络环境下下载，避免直接发起GET请求占满带宽造成卡顿。

需要额外提醒的是：Yii2框架下HEAD请求会完整执行GET请求的全部服务端逻辑，包括数据库查询、权限判断、频率限制，并非“轻量请求”，它节省的只是网络传输阶段的流量，不会降低服务端的业务处理开销。

内容的提问来源于stack exchange，提问作者trejder