Robot截屏后需将BufferedImage转为JPEG/PNG字节流：先转TYPE_INT_RGB（避JPEG黑图），再用ImageWriter编码；Socket传输须加4字节长度头防粘包；Linux需Xvfb虚拟显示；UI更新须用SwingWorker+invokeLater。
Robot截屏后怎么转成可网络传输的图片格式
直接用 Robot.createScreenCapture() 拿到的是 BufferedImage，不能直接发 HTTP 或 Socket。必须压缩编码成字节流，常见选 JPEG（体积小、兼容好）或 PNG（支持透明，但局域网截图一般不需要）。别用 ImageIO.write(img, "BMP", ...) —— BMP 无压缩，1920×1080 截图轻松超 6MB，传一次卡两秒。
- 用
ImageIO.write(img, "JPEG", output)，output是ByteArrayOutputStream - JPEG 质量可调：通过
JPEGImageEncoder（旧）或ImageWriter+IIOImage（新），推荐后者，Java 9+ 更稳定 - 注意：
BufferedImage.TYPE_INT_ARGB截出来的图带 alpha 通道，但 JPEG 不支持，强行写会变黑——得先转成TYPE_INT_RGB：new BufferedImage(w, h, BufferedImage.TYPE_INT_RGB)，再用Graphics2D绘制原图
Socket传图时为什么客户端总收不全或花屏
根本原因是 TCP 是流式协议，InputStream.read() 不保证一次读完所有字节。服务端发了 123456 字节，客户端可能分 3 次收到：45000、65536、12920 —— 如果没处理分包/粘包，直接当一张图解码，必然失败。
- 服务端发图前，先写 4 字节长度头：
DataOutputStream.writeInt(bytes.length) - 客户端用
DataInputStream.readInt()先读长度，再循环read()直到凑够该长度 - 别用
BufferedReader.readLine()读二进制图，它按换行切，彻底乱码 - 局域网建议关 Nagle：
socket.setTcpNoDelay(true)，减少小包延迟
Robot在无界面环境（如 Linux 服务端）跑不起来报 headless 错误
java.awt.HeadlessException 不是配置问题，是 JVM 真的没图形上下文。Linux 后台运行 Java 进程默认 headless=true，Robot 直接拒绝初始化。
- 开发机 Windows/macOS 没这问题；部署到 Linux 服务器时，必须确保有 X11 显示（比如用
Xvfb虚拟帧缓冲） - 启动命令示例：
Xvfb :99 -screen 0 1920x1080x24 && DISPLAY=:99 java -jar screenshot.jar - 别信“加
-Djava.awt.headless=false就行”——这参数只对部分 AWT 组件生效，Robot仍会检查真实显示环境 - Docker 容器里更麻烦，需挂载
/tmp/.X11-unix或用--shm-size=2g配合Xvfb
怎么让接收端实时刷新截图而不卡死 UI
Swing/AWT 的事件线程（EDT）不能干耗时事。如果把 socket 接收 + 图片解码 + repaint() 全塞进 actionPerformed，UI 会假死，且丢帧严重。
立即学习“Java免费学习笔记（深入）”；
- 用
SwingWorker或单独线程收图，解码完用SwingUtilities.invokeLater()更新 JLabel 的 icon - 别每次截图都 new ImageIcon：
imageIcon.setImage(bufferedImage)复用对象，避免 GC 压力 - 加简单帧率控制：服务端每秒最多推 5–10 帧，用
Thread.sleep(100)限频，否则千兆网也扛不住高频全屏抓取 - 客户端收到图后，先检查宽高是否和上次一致，不变就跳过
revalidate()，省掉 layout 开销
局域网截图工具最难的不是截，是稳住传输链路和渲染节奏。很多人在 Robot 成功那一刻就以为搞定了，其实后面 socket 分包、线程调度、headless 兼容才是真坑点，而且一跑生产环境就暴露。
