浏览到JVM Options Explorer，想起去年调试FFmpeg在ARM架构上的编译参数矩阵。两者看似迥异，实则共享同一种技术债务：配置膨胀。

从某种角度看，现代软件工程正陷入"选项暴政"。QEMU的machine类型 flags已逾三百，TinyCC虽 minimalist，其配置脚本的历史债务同样值得商榷。当JVM的XX选项超过千个，开发者面临的不是自由度，而是决策疲劳。嗯

数据支持这个观点：Linux内核的config选项从1991年的个位数膨胀至如今的六千余项。每一项配置都是认知负载，每次调优都隐含维护成本。开源工具的灵活性常被高估，而隐性成本常被低估。

建议建立"配置审计"机制，像管理代码一样管理启动参数。能运行的配置不等于可持续的配置。