BufferedOutputStream 仅在IO层缓冲字节以减少系统调用，不参与SMTP协议或附件逻辑；附件发送由JavaMail等库按MIME规范编码并控制，批量发邮件应复用Session/Transport而非缓存原始协议数据。
BufferedOutputStream 本身不参与 SMTP 协议层的附件发送逻辑，也不能直接“缓存字节用于批量发邮件”——它只是对底层 OutputStream 做内存缓冲，真正决定附件如何写入、何时发送的是你使用的 SMTP 客户端库（如 JavaMail / Jakarta Mail）和你的代码组织方式。
理解 BufferedOutputStream 的实际作用
它在 IO 层把多次小 write() 合并成一次较大的系统调用，减少磁盘或网络写入次数。但 SMTP 发送是应用层协议：附件内容需按 MIME 格式编码（Base64 或 quoted-printable），封装进邮件体，再通过 Socket 连接发给 SMTP 服务器。这个过程由邮件库控制，不是直接把字节丢给 BufferedOutputStream 就能“缓存一批再发”。
正确做法：让邮件库处理附件流，BufferedOutputStream 用在合适位置
如果你要高效添加大附件（比如从文件读取），可以这样配合使用：
- 用 FileInputStream 读取附件原始字节
- 包装成 BufferedInputStream（提升读取效率，非必须但推荐）
- 交给 MimeBodyPart 的 setDataHandler() 或 attachFile() —— JavaMail 内部会按需读取并编码写入最终输出流
- 最终整个 MimeMessage 写入到一个 SocketOutputStream 时，可再套一层 BufferedOutputStream（例如
new BufferedOutputStream(socket.getOutputStream(), 8192)），减少 TCP 包数量
批量发送多封邮件时的缓存与优化关键点
“批量”指的是发 10 封带附件的邮件，不是把 10 个附件塞进一封邮件里：
立即学习“Java免费学习笔记（深入）”；
- 复用 Session 和 Transport（保持连接，避免反复握手）
- 每封邮件独立构建 MimeMessage，附件流按需打开/关闭（不要提前全读进内存）
- 如果附件来自同一文件，可用 FileChannel.transferTo() 或 NIO 零拷贝加速；若来自 byte[]，直接用 ByteArrayDataSource
- 不要手动用 BufferedOutputStream 拼接多封邮件的原始协议数据 —— SMTP 要求每封邮件单独以
DATA命令开始，协议层不支持“缓存多封再发”
一个小而安全的示例片段（JavaMail + 缓冲）
假设你正通过 socket 手动写 SMTP（不推荐，仅说明缓冲位置）：
Socket socket = new Socket("smtp.example.com", 587);
OutputStream rawOut = socket.getOutputStream();
// 在这里加缓冲，作用于最终网络写出
BufferedOutputStream out = new BufferedOutputStream(rawOut, 16384);
PrintWriter writer = new PrintWriter(out);
// ... 发送 HELO, AUTH, MAIL FROM 等命令
writer.println("DATA");
writer.flush(); // 刷新命令
// 此时才写邮件体（含 Base64 编码后的附件）
writeMimeMessageToStream(message, out); // 该方法内部可能用 BufferedOutputStream 包装了 part.getInputStream()
out.flush(); // 确保附件数据发出
writer.println(".");
writer.flush();
