PHP stream_filter_remove 怎样只移除输出流上的压缩过滤器

如果只想移除输出流上的某一个压缩过滤器，关键是保存 stream_filter_append() 返回的过滤器资源，再把这个资源传给 stream_filter_remove()。不要把文件流资源、过滤器名称或字符串 zlib.deflate 传进去。

官方地址：https://www.php.net/manual/en/function.stream-filter-remove.php

正确的切换顺序是“保存过滤器句柄 → 调用 stream_filter_remove → 检查布尔返回值 → 再写入后续内容”。移除动作会先把该过滤器内部尚未处理的缓冲刷新到后续过滤器；它只改变过滤器链，不会替你把已经写出的压缩数据还原成普通文本。

先分清要移除的是过滤器实例

stream_filter_append() 成功时返回一个可以代表该过滤器实例的资源，失败时返回 false。stream_filter_remove() 接受的正是这个实例资源，所以同一条流上即使挂了多个过滤器，也可以只针对其中一个句柄操作。

用句柄移除写方向上的压缩过滤器

下面的例子把过滤器明确挂在 STREAM_FILTER_WRITE 方向。写入第一段时会经过 zlib.deflate；移除返回的句柄后，后续写入不再经过这一项。示例中的中文注释只解释关键边界，不把每一行都机械翻译。

这里生成的文件不能简单当作“完整的 deflate 文件”或“完整的普通文本文件”：前半段可能已经是压缩字节，后半段则是移除过滤器后的原文。动态移除适合有明确分段协议的场景，不适合让下游只按一种格式连续解码。

为什么移除后仍可能看到一小段压缩数据

过滤器处理流数据时可能保留内部缓冲。官方说明指出，移除过滤器前，剩余缓冲会先刷新到后续过滤器，然后过滤器才从链中移除。因此，调用 stream_filter_remove() 不是“丢弃过滤器缓存”，也不是把缓存内容解压后再交给调用方。

最容易误判的三个边界

只想关掉压缩，不要误传流资源

$fp 是目标流，$deflate 才是过滤器实例。把前者传给移除函数，表达的对象就错了；把过滤器名称传进去也不能定位某一个实例。过滤器句柄应该在挂载成功后立即保存，并和对应的读写方向一起管理。

读过滤器和写过滤器是两条链

STREAM_FILTER_WRITE 只影响写出路径，STREAM_FILTER_READ 只影响读入路径。如果同一个过滤器名称同时挂在读写两侧，PHP 会创建两个过滤器实例，需要分别保存两个返回值，不能用一个句柄代替另一侧。

移除不等于格式转换

移除操作不会把前面已经压缩的内容转换成原文，也不会为后续原文自动添加协议分隔符。若消费者需要安全切换，应该在应用层设计分段头、长度、编码标志或独立资源；如果协议只有一种编码方式，通常应关闭整条输出流程后重新建立新的资源，而不是在同一文件中拼接两种格式。

失败处理应该保留哪些信息

函数返回 true 表示移除成功，返回 false 表示失败。生产代码至少要记录目标流的业务标识、过滤器挂载阶段和移除阶段；不要只记录“输出失败”，否则很难区分句柄已经失效、过滤器没有成功挂载，还是资源生命周期已经结束。

什么时候应该改用重新建立输出流

如果输出对象是一个需要被单一解码器读取的压缩文件、HTTP 响应体或归档成员，不建议在中途移除压缩过滤器后继续写同一对象。更稳妥的方式是让压缩区段和原文区段拥有清晰的容器边界，或者分别写入不同资源，再由上层协议描述它们的编码。

只有当下游明确知道“前一段按压缩格式读取，后一段按原文读取”，并且双方都能处理过滤器刷新带来的边界时，才适合在同一流里动态切换。否则，stream_filter_remove() 虽然调用成功，最终文件仍可能无法被预期的读取器解析。

小结

常见问题

可以按过滤器名称移除吗？

不可以。应保存具体实例的返回资源，再传给 stream_filter_remove()。

移除后会丢掉过滤器缓冲吗？

不会。移除前的剩余缓冲会先向后刷新；这也是切换格式时必须设计边界的原因。

一个过滤器句柄能同时控制读和写吗？

不能把它当成两条链的通用开关。读写方向分别挂载时，应分别保存和移除对应实例。