在Ruby 3.1之后引入的IO::Buffer为底层IO操作提供了直接操作内存的能力，而其中的slice方法是最具迷惑性的一个。它表面上看起来像Array#slice那样会返回一个新对象，实际上返回的是一块共享内存的视图，原始缓冲区一旦被释放或改变大小，视图就可能变成悬垂引用。理解这一点，是安全使用IO::Buffer的前提。
slice到底返回了什么：零拷贝视图的本质
先看一个最基础的例子，创建一个缓冲区并对它做slice：
require 'io/buffer' buf = IO::Buffer.new(64) buf.set_value(:U32, 0, 0x11223344) # slice返回从偏移8开始、长度16字节的视图 view = buf.slice(8, 16) puts view.size # => 16 puts view.inspect
关键在于：slice不会复制任何字节。它内部创建了一个新的IO::Buffer对象，但这个对象的内存指针直接指向原始缓冲区内部偏移8字节的位置，长度固定为16字节。可以从输出中看到视图被标记为readonly的来源信息，它明确标注了父缓冲区。这意味着对视图的写入会直接反映到原始缓冲区上（在权限允许的情况下），反过来也一样。
与之对照的是copy方法：
buf = IO::Buffer.new(64) dup = buf.copy(0, 64) # 真正分配64字节新内存并复制内容 view = buf.slice(0, 64) # 只是视图，零分配 # 修改原始缓冲区 buf.set_value(:U8, 0, 255) puts dup.get_value(:U8, 0) # => 0，副本不受影响 puts view.get_value(:U8, 0) # => 255，视图同步变化
这个对比清晰地展示了两种语义：copy是值语义，代价是内存分配和数据搬运；slice是引用语义，代价是生命周期耦合。在解析网络协议时，协议头和载荷往往在同一个缓冲区里，用slice把载荷部分切出来交给下游处理，可以避免一次甚至多次大块内存拷贝，这正是它被设计出来的目的。
视图与原始缓冲区的生命周期关系
零拷贝的代价是生命周期约束。视图本身不拥有内存，它的有效性完全依赖原始缓冲区。在MRI实现中，IO::Buffer内部维护了引用计数：当通过slice创建视图时，原始缓冲区的引用计数会增加；视图被GC回收时计数减少。这保证了视图存活期间，底层内存不会被释放。
也就是说，下面这种写法是安全的：
def make_view
buf = IO::Buffer.for("hello world")
buf.slice(0, 5) # 方法返回后buf变量超出作用域
end
view = make_view
puts view.null? # => false，引用计数保证了内存仍然有效
但生命周期安全不等于数据一致性安全。引用计数只保证内存不被释放，不保证内容不被修改。如果原始缓冲区被clear清零、被resize重新分配（resize可能触发realloc，导致内存整体搬家），视图的状态就会出问题。特别是resize：
buf = IO::Buffer.new(32, IO::Buffer::EXTERNAL) view = buf.slice(0, 32) begin buf.resize(1024) rescue IOError => e puts e.message # 有视图存在时resize可能被拒绝 end
对于内部缓冲区，resize在存在活动视图时的行为取决于Ruby版本，较新的版本会更加保守，要么抛出IOError，要么让视图失效。这属于防御性设计：与其让视图静默指向一块已搬迁的旧内存，不如直接报错。实践中应当遵循一条规则：视图的使用窗口内，不要对原始缓冲区做结构性修改，包括resize、clear、以及映射文件的重新映射。
权限传递、只读视图与常见陷阱
slice会继承原始缓冲区的读写权限，但可以通过readonly方法显式降级。这在把数据交给不可信的下游代码时很有用：
buf = IO::Buffer.new(16)
view = buf.slice(0, 16).readonly
begin
view.set_value(:U8, 0, 1)
rescue IOError, NoMethodError => e
puts "写入被拒绝: #{e.class}"
end
# 原始缓冲区仍然可写
buf.set_value(:U8, 0, 1) # 正常
一个常见的坑是把slice的结果长期缓存起来。比如在事件循环里用一个全局缓冲区接收数据，把slice视图存进某个对象的实例变量，等下一轮事件覆盖缓冲区内容后，缓存的视图读到的已经是新数据。这种bug的特点是数据看起来随机错乱、难以复现。解决办法有两个：要么在缓存前调用copy转为独立副本，要么每次使用前重新slice。
另一个坑与字符串相关。IO::Buffer.for("string")创建的缓冲区直接引用字符串的内存，此时对字符串做任何修改（包括String#<<触发扩容）都可能让视图失效。务必保证作为宿主的字符串被freeze，让缓冲区和视图都处于只读状态，这样最安全。
实战建议：什么时候用slice，什么时候用copy
总结几条实践中沉淀下来的判断标准。第一，短生命周期的解析场景用slice：数据在同一次调用内被读取完毕，视图不会逃逸出当前作用域，零拷贝收益最大。第二，需要长期持有或跨线程传递时用copy：虽然多一次内存分配，但彻底解耦了生命周期。第三，大块数据只处理其中一小段时优先slice：比如从1MB的缓冲区里解析一个16字节的头部，复制1MB显然不合理。
一个典型的协议解析模式如下：
def parse_packet(buf) # 协议头：4字节长度 + 2字节类型 length = buf.get_value(:U32, 0) type = buf.get_value(:U16, 4) # 载荷视图，零拷贝 payload = buf.slice(6, length) case type when 1 then handle_text(payload) # 视图在本次调用内消费 when 2 then handle_binary(payload) end end
最后提醒一点调试技巧：怀疑视图失效时，用inspect查看视图的base和size信息，用null?和empty?判断状态，必要时在关键节点对比get_value的读取结果。理解了零拷贝视图与原始缓冲区之间的这份契约，IO::Buffer就能成为Ruby中处理高性能IO的可靠工具，而不是内存bug的来源。
Ruby IO::Buffer零拷贝缓冲区生命周期修改时间：2026-09-07 15:00:51