io编程到底在解决什么问题
程序运行时，数据总要进出：读文件、收网络包、写日志、访问数据库。io编程处理的正是这类“与外部世界交换数据”的过程。
它与纯计算最大的不同在于速度差。CPU 运算以纳秒计，磁盘寻道以毫秒计，网络往返可能上百毫秒。io编程的大部分技巧，都是围绕这个数量级差异展开的：要么减少等待，要么让等待期间干别的活。
阻塞与非阻塞：先分清两件事
很多人把“阻塞”和“同步”混为一谈。可以这样拆开看：
- 阻塞/非阻塞：描述调用方在等待结果时的状态。阻塞调用会挂起当前线程，非阻塞调用立即返回，告诉你“还没好”。
- 同步/异步：描述结果如何交付。同步由调用方主动查询或等待，异步由系统在完成后通知。
常见组合里，阻塞同步最直观：read() 一直等到数据到达。非阻塞同步需要轮询，代码简单但空转浪费 CPU。异步模型则把“等待”交给运行时或操作系统，回调、Future、协程都是它的表现形式。
选型没有绝对优劣。连接数少、逻辑简单时，阻塞写法可读性最好；高并发场景下，异步或事件驱动才能撑住连接数。
缓冲与流式：别让小块 IO 拖垮性能
一次读一个字节，和一次读 8KB，系统调用次数差几千倍。io编程里最容易被忽视的优化就是加缓冲。
带缓冲的流把多次小读写合并成少量大操作，显著降低上下文切换和系统调用开销。但缓冲也有代价：数据先落在内存里，写入时机变得不透明。涉及崩溃一致性时，需要显式刷新，并理解刷新与落盘不是一回事。
流式处理则解决另一个问题：数据量大到不能整体载入内存。边读边处理、边算边写，内存占用恒定。日志分析、文件传输、大结果集遍历都适合这种模式。
几个实用的避坑点
一是别在 IO 路径上做重计算。 读到大块数据后立刻做复杂解析，会占住处理线程，削弱并发模型的收益。必要时拆成“读取—入队—异步处理”。
二是注意资源释放。 文件句柄、连接、缓冲区都有限。用语言提供的自动管理机制，或确保异常路径也能关闭。
三是区分超时与失败。 网络 IO 里超时很常见，把它当成可重试的正常分支，而不是异常崩溃。
四是量力而行地优化。 先测量再改。很多所谓 IO 瓶颈，其实是锁竞争或序列化开销。
小结
io编程的功夫不在记住多少接口，而在于对“等待”的敏感：知道哪里会等、等多久、等待时能否做别的事。把阻塞模型、缓冲策略和流式思路理清楚，再结合具体语言提供的异步能力，就能写出既不空转也不死等的代码。
