IllegalComponentStateException主因是Swing组件未添加到容器就调用setVisible()等依赖容器上下文的方法；须先add()再setVisible()、pack()等，且所有UI操作必须在EDT中执行。
Swing组件调用setVisible(true)前没加到容器里会抛IllegalComponentStateException
这个异常不是线程安全问题，也不是空指针，而是Swing在内部校验组件“是否已归属某个顶层容器”时失败触发的。典型场景是新建了JButton或JTextField，直接调用setVisible(true)或requestFocus()，但还没用add()加进JFrame或JPanel。
实操建议：
- 所有非顶层组件（比如
JButton、JLabel、JTable）必须先调用container.add(component)，再做可见性、焦点、尺寸相关操作 - 如果要提前配置组件（比如设文字、监听器），没问题；但只要涉及
setVisible()、requestFocus()、getPreferredSize()、repaint()等依赖容器上下文的方法，就得确保它已被添加 - 调试时可加一句
System.out.println(component.getParent() != null);快速验证——返回false就说明还没加进去
pack()和setVisible(true)顺序颠倒导致IllegalComponentStateException
pack()本质是让顶层窗口（JFrame/JDialog）根据子组件计算并设置自身大小。它要求所有子组件已添加完毕，且不能在窗口已显示后再调用。
常见错误现象：窗口闪一下就崩溃，堆栈里出现IllegalComponentStateException，源头常指向pack()内部的validate()调用。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 严格按顺序写：
frame.add(...)→frame.pack()→frame.setVisible(true) - 千万别在
setVisible(true)之后又调用pack()，哪怕只是想“重算大小”——这会触发非法状态校验 - 如果运行时动态增删组件并想更新布局，用
revalidate()+repaint()，而不是pack()
在SwingUtilities.invokeLater()外操作GUI组件引发状态不一致
这个异常有时不直接报在你写的代码行，而是出现在事件分发线程（EDT）内部调度时，因为组件状态在非EDT线程里被意外修改过（比如后台线程调了setText()或setEnabled(false)），导致EDT后续操作时发现状态矛盾。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
使用场景：从网络加载数据后更新JLabel文字，但忘了切回EDT。
实操建议：
- 任何对Swing组件的读/写操作（包括
getText()、isEnabled()这类看似只读的方法）都必须在EDT中执行 - 后台任务结束后，用
SwingUtilities.invokeLater(() -> { label.setText("done"); })包裹UI更新逻辑 - 不要依赖“这个组件好像没崩，所以可以跨线程操作”——状态检查可能延迟触发，问题会偶发且难复现
自定义JComponent子类重写paintComponent()时没调用super.paintComponent(g)
虽然这通常导致绘图异常或背景残留，但在某些JDK版本（如8u202+）和特定L&F下，若组件尚未完成初始化就被强制重绘，也可能触发IllegalComponentStateException——因为super.paintComponent()里隐含对isDisplayable()和容器链路的校验。
性能影响：漏掉super调用不仅有视觉问题，还会干扰Swing内部的状态缓存机制，使后续repaint()行为不可预测。
实操建议：
- 所有重写
paintComponent(Graphics g)的地方，第一行必须是super.paintComponent(g) - 如果需要清屏，用
g.clearRect(0, 0, getWidth(), getHeight())，别试图绕过super - 调试时临时加个
if (!isDisplayable()) { System.err.println("paintComponent called before displayable"); return; }能快速定位时机问题
最麻烦的是这个异常不总在出问题的那一行抛，可能滞后一两个方法调用才爆发。一旦看到它，优先检查组件是否真的“挂”在了容器树上，而不是急着看线程或监听器——90%的情况，getParent() == null就是根源。
