代码虽不产生物理垃圾，但低效冗余会制造“数字垃圾”，如内存泄漏、重复计算、过度日志、冗余依赖等，拖慢系统、浪费算力、推高碳排放；需通过精简对象生命周期、删减冗余逻辑、克制日志输出、轻量依赖引入来提升简洁性、可维护性与运行效率。
写代码本身不产生物理垃圾，但低效、冗余或不规范的代码会带来“数字垃圾”——比如内存泄漏、无用对象堆积、重复计算、过度日志、冗余依赖等。这些会拖慢系统、增加运维成本、浪费算力资源，间接推高能源消耗和碳排放。减少这类垃圾，本质是提升代码的简洁性、可维护性和运行效率。
精简对象生命周期，避免内存堆积
很多垃圾来自本该及时释放却长期滞留的对象。比如在循环中反复创建大对象、缓存未设上限、监听器未解绑、流未关闭等。
- 用 try-with-resources 自动关闭 InputStream、Connection 等资源
- 集合类缓存加 LRU 或过期策略（如 Caffeine），避免无限增长
- 事件监听或回调注册后，确保在对应生命周期结束时 显式移除
- 避免在长生命周期对象（如单例、Activity）中持有短生命周期对象的强引用（防内存泄漏）
删减冗余逻辑与重复计算
重复执行相同运算、多次查数据库、反复解析同一 JSON、条件分支嵌套过深，都会制造“计算垃圾”。它不占内存，但浪费 CPU 和时间。
- 把不变的中间结果 提取为局部常量或缓存变量，而非每次重新计算
- 用 提前返回（guard clause） 替代深层 if-else 嵌套，让主逻辑更清晰、路径更短
- 数据库查询优先用 WHERE 过滤而非 Java 层过滤；JSON 解析后复用对象，别反复 parse
- 对高频调用方法，考虑是否真需每次都执行——能否惰性加载、按需触发或合并批量处理？
克制日志与调试痕迹
开发期随手打的 log.info、console.log 或 print，上线后若未清理，会持续写磁盘、占带宽、干扰排查，属于典型的“噪音垃圾”。
- 生产环境默认关闭 DEBUG 级别日志，INFO 也只保留关键业务节点
- 避免在循环内打印日志；必须打时，用 条件判断包裹（如
if (log.isDebugEnabled()) { log.debug(...); }） - 删除调试用的
System.out、断点残留代码、临时 mock 数据生成逻辑 - 用结构化日志（如 JSON 格式）替代拼接字符串，便于采集与过滤，减少后期清洗成本
轻量依赖与按需引入
一个功能只用到某个库的 2% 却引入整个 jar 包，或为了一个小工具引入重量级框架，会显著增大部署包体积、启动时间和内存占用。
- 优先选 专注单一职责的小而美库（如用
tinylog替代log4j，用gson替代jackson-databind若只需基础 JSON） - 检查 Maven/Gradle 依赖树（
mvn dependency:tree），剔除 传递依赖中的无用项 - 前端项目用 动态 import() 实现路由/组件懒加载，避免首屏加载巨包
- 服务端函数（如 AWS Lambda）尽量裁剪运行时环境，去掉未使用的 SDK、字体、本地化资源等
代码的“洁净度”不是靠删减功能实现的，而是通过克制、预判和持续审视达成的。每一次提交前问一句：“这段代码有没有更少、更稳、更省的方式？”——就是在为系统减负，也在为环境减负。
