245MB vs 12KB：一个开发者的地球日代码瘦身实验

一个标准React脚手架占用245MB磁盘空间，而纯手写HTML/CSS/JS方案仅需12KB——相差两万倍的背后，是数据中心里持续运转的CPU和真实存在的电费账单。

「我不为奖金，只为完成徽章」

这篇投稿来自一位匿名开发者，参加的是DEV社区的「地球日周末挑战」。他开篇就划清界限：不做AI工具，不跑区块链节点，「纯粹作为参与者」。

他的「项目」没有上线任何新应用。理由很直接：「我不想让新应用躺在服务器上白白烧电。」

取而代之的，是一份《精益网页架构标准》——给自己未来项目用的开发规范。

臃肿的代价：每一行多余代码都在耗电

作者算了一笔账。数据中心的电力往往来自化石燃料，而教程里推崇的「 heavier frameworks, more API calls, and bloated libraries」（更重的框架、更多API调用、臃肿的库）直接推高能耗。

他用终端命令做了直观对比：

React脚手架方案：245MB

纯手写方案：12KB

差距不是几倍，是20480倍。

作者的核心论点：服务器处理12KB静态文件所需的CPU周期，远低于编译和注水（hydrate）庞大JavaScript包的消耗。「Less CPU = less power = lower emissions」（更少CPU=更少电力=更低排放）。

三条实操规则

这份个人标准聚焦三件事，原文未展开细节，但从上下文可还原其指向：

第一，用原生代码替代依赖。作者明确提到「relying on vanilla code instead of dragging in 500MB of node_modules」（依赖原生代码而非拖入500MB的node_modules）是他眼下最可行的环保动作。

第二，服务端处理替代客户端重逻辑。示例显示，用.htaccess文件处理路由和缓存，而非引入重型JavaScript库。

第三，缓存即绿色技术。作者称「Caching is arguably the best 'Green Tech'」（缓存堪称最佳「绿色技术」），因为它能避免服务器重复处理相同请求。

他贴出的.htaccess配置包括：图片缓存一年、CSS/JS缓存一个月、URL重写简化后端解析。

为什么是现在？

这个实验的微妙之处在于时机选择。地球日挑战通常催生「种树计数器」或「碳足迹计算器」这类应用——它们本身也是新部署的服务器负载。

作者反其道而行：用「不构建」来构建。这种自我约束指向一个被忽视的真相——开发者工具链的膨胀速度远超业务需求的增长速度。

245MB的脚手架里，真正服务于「简单店铺页面」的代码占比极低。剩余部分是开发体验优化（热更新、语法转换、打包分析）、潜在功能预留、以及层层嵌套的依赖依赖。

12KB方案牺牲了这些，但保留了核心交付能力。

争议与边界

作者的方法论有明显适用范围。他自认技术栈是「HTML, CSS, JavaScript, and PHP」——这是经典服务端渲染路线，与React代表的客户端渲染范式存在架构分歧。

原文未声称此法适用于所有场景。没有数据证明「所有React应用都可被PHP替代」，也没有企业案例支撑「12KB方案在大型项目中同样高效」。

但作者的论证严格限定在个人项目维度：「for my own future projects」（针对我自己的未来项目）。这是一种个体层面的技术债务清理，而非行业宣言。

数据收束

245MB到12KB的对比是夸张的，但作者提供的终端截图（或伪代码）格式让它可被复现验证。关键数字未被模糊处理：React脚手架245MB，手写方案12KB，缓存周期精确到「1年」和「1个月」。

这个实验的真正价值不在于推广PHP，而在于提出一个可量化的自检问题：你的工具链体积，是否已经超过你实际交付的功能所需？