Swing单位转换界面关键点：用JComboBox选预设单位、JTextField仅输数字且延迟计算、换算统一经基准单位（如长度用m）、温度注意273.15偏移、重量区分吨与盎司、日志更新须在EDT线程、资源用getResource加载。
用 Swing 实现基础单位转换界面的关键点
Java GUI 做单位转换计算器，Swing 是最直接的选择——无需额外依赖，JDK 自带，适合教学和轻量工具。核心不是“画得多漂亮”，而是控件间数据流清晰、事件响应不卡顿、单位逻辑不耦合。
常见错误是把所有逻辑塞进 ActionListener 里，导致修改一个换算关系就得翻遍整个 actionPerformed 方法。应该把“输入 → 单位类型 → 换算系数 → 输出”拆成可替换的模块。
-
JComboBox用于选择源单位和目标单位，必须预先定义好单位组（如长度：mm/cm/m/km），不能让用户自由输入 -
JTextField只负责接收数字字符串，**不做实时计算**；触发时机应限定在回车或点击“转换”按钮，避免DocumentListener频繁解析非法输入 - 所有换算系数统一用
double存储，避免整数除法截断（比如1 / 1000得 0）
长度/温度/重量三类单位的换算逻辑怎么组织
硬编码 if-else 判断单位组合会导致维护爆炸。推荐用“基准单位归一法”：每类单位选定一个内部基准（如长度用 m，温度用 K，重量用 g），所有输入先转基准，再转目标。
例如温度：用户输入 25℃ → 转为 298.15K → 再转成 77℉。这样新增单位（如 °R）只需加两行系数，不用改分支逻辑。
立即学习“Java免费学习笔记（深入）”；
public static double celsiusToKelvin(double c) { return c + 273.15; }
public static double kelvinToFahrenheit(double k) { return k * 9.0 / 5.0 - 459.67; }
// 调用链：input → toKelvin() → toFahrenheit()- 避免使用
String.equals("cm")做判断，改用枚举Unit.LENGTH_CM提升可读性和编译检查 - 摄氏与华氏之间没有线性偏移以外的变换，但别漏掉
0℃ = 32℉这个常量偏移项，写成(c * 9/5) + 32才对 - 重量单位注意吨（
t）是 1000kg，不是 1000g；盎司（oz）按国际常衡制取 28.3495g
为什么 JTextArea.append() 在转换中容易出错
很多初学者用 JTextArea 当日志窗口，每次转换都调用 append()，结果界面卡死或文字重叠。根本原因是没控制更新频率，且未在 Event Dispatch Thread 中安全操作 UI。
- 不要在耗时计算（如批量转换）中频繁调用
append()，应攒一批结果后用单次setText() - 如果真要逐行追加，必须确保在 Swing 线程执行：
SwingUtilities.invokeLater(() -> resultArea.append("done\n")); - 更稳妥的做法是把日志输出抽离成
Consumer<string></string>回调，UI 层只负责绑定，业务逻辑不感知 Swing
打包成 jar 后单位配置无法加载的典型原因
本地 IDE 运行正常，导出 jar 后 FileNotFoundException 或单位列表为空——大概率是资源路径写错了。
- 别用
new File("units.json")，这是相对路径，jar 包里不存在该文件系统路径 - 正确方式是
getClass().getResource("/config/units.json")，确保文件放在src/main/resources/config/下 - 如果用
Properties加载单位映射，注意键名大小写（length.m和length.M是不同键） - IDE 中运行时 classpath 包含
src/main/resources，但 jar 包需确认该目录被打包进去（Maven 项目看target/classes/config/是否存在）
单位转换本身不难，难的是让不同量纲的换算规则能独立增删、系数不写死、错误输入有反馈、打包后不丢配置。这些地方一旦忽略，后续加货币汇率或面积单位就会推倒重来。
