为何同一Swing可执行Jar在不同电脑运行时组件尺寸被挤压？

• 高DPI系统的缩放适配偏差：你当年开发时的旧电脑一般默认使用100%系统缩放（对应96DPI的显示基准），代码里写的窗口尺寸、组件尺寸都是基于这个基准计算的。新电脑如果开启了125%/150%等更高的系统缩放比例，而旧版本Swing程序没有开启DPI感知能力，JVM会直接把代码里的像素值当成物理像素使用，既不会跟随系统缩放比例自动换算尺寸，也匹配不了新环境下更大的字体渲染尺寸需求。
  这种情况下，你硬编码的JFrame固定尺寸在物理屏幕上的实际大小和旧电脑一致，但新环境下更高的像素密度、更大的系统字体渲染需求会挤占内部布局的可用空间；搭配GridBagLayout布局时，组件本来需要的显示空间不足，就会出现被挤压的情况。你手动放大JFrame的尺寸，本质是补够了高DPI环境下需要的额外像素空间，组件自然就能恢复正常显示。
• 硬编码尺寸的设计缺陷：你通过setPreferredSize(new Dimension(硬编码宽, 硬编码高))手动覆盖组件尺寸的写法，完全没有考虑不同运行环境的差异——不同操作系统对Swing组件的默认渲染规则、系统默认字体大小都有区别，哪怕DPI比例一致，硬编码的尺寸也可能无法匹配组件实际的显示需求。

• 启动程序时开启JVM的高DPI自动适配能力：
• Java 9及以上版本，默认已支持系统DPI感知，不需要额外配置
• Java 8及更早版本，可在启动参数中添加-Dsun.java2d.dpiaware=true、-Dsun.java2d.uiScale=auto，让Swing自动跟随系统缩放比例换算所有组件的显示尺寸，避免硬编码像素值和实际物理像素的映射偏差。
• 放弃手动硬编码组件尺寸的写法，依靠布局管理器自动计算合理尺寸：
• 对JTextArea这类需要指定显示范围的组件，不要手动覆盖preferredSize，直接使用构造方法传入行数、列数的参数，让布局管理器结合当前字体、DPI自动计算适配的显示大小
• 对JSlider、JFormattedTextField这类有固定默认渲染尺寸的组件，直接使用默认的尺寸计算逻辑即可，不要随意手动设置固定宽高。
• 固定窗口大小时，不要直接硬编码像素值：在所有组件初始化、排版完成后，调用JFrame.pack()方法，让布局管理器根据所有组件自动计算出的preferredSize总和，生成刚好适配所有组件需求的窗口尺寸，再配合setResizable(false)固定窗口大小。这种方式生成的窗口尺寸，会自动匹配当前运行环境的DPI、字体大小，不会出现布局空间不足挤压组件的问题。
• 若需要自定义组件尺寸，要基于当前运行环境的UI指标换算，比如根据当前组件的字体字号计算需要的宽高，而非直接写死像素值，从根源上避免不同环境的尺寸适配偏差。

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