DispatchSource.makeReadSource与DispatchIO.read：两类API的共存原因及选型疑问

为什么会同时提供这两类API？ #

• 核心定位不同：看似功能重叠，实则一个主打通用事件监听（比如捕获fd的读写就绪、异常等基础事件），另一个聚焦高效IO流处理（封装了批量读写、缓冲区管理、流控等上层逻辑），解决的是不同层级的问题。
• 历史迭代产物：早期先推出了基础的事件监听API，覆盖简单场景；后来为了降低高并发IO（比如大文件传输、持续网络流）的开发复杂度，才针对性推出了更上层的IO封装API。保留老API一是为了兼容存量代码，二是给需要精细控制的场景留足灵活度。
• 粒度控制需求不同：一类给开发者最细的控制粒度——每一次fd事件触发都能自定义处理逻辑；另一类把繁琐的缓冲区管理、循环读写等逻辑封装起来，让开发者聚焦业务逻辑，满足不同开发风格和场景的需求。

优先选择哪一类？ #

优先选通用事件型API的场景： #

• 只需要监听fd的特定事件（比如仅监听错误事件，或者自定义读写触发时机）
• 已经有自己的缓冲区管理、读写逻辑，不需要上层API的封装
• 需要和其他Dispatch事件（比如定时器、信号监听）做联动处理

优先选IO流型API的场景： #

• 处理大文件、网络流这类需要批量读写的场景，希望自动处理缓冲区、流控，减少手动编码量
• 追求代码简洁，不想自己实现fd就绪后的读写循环、异常重试等逻辑
• 需要使用分段传输、自动拼接数据等高级IO特性，API已内置支持

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