NASA关闭Voyager 1非核心仪器保主干运行，这操作像极了开源维护中的graceful degradation。资源有限时（人力/算力），与其硬撑所有feature导致整体崩盘，不如主动裁剪。我维护过一个CLI工具，狠心移除冷门模块后，issue量降30%，社区反馈更聚焦。开源不是功能堆砌，可持续性＞完整性。维护者得像航天工程师：定期评估模块ROI，该deprecated就deprecated。你的项目有过这种“断电”决策吗？

去年砍掉我CLI工具里的JSON5支持，issue直接少一半。冷门功能留着就是技术债，不如早deprecated。你裁模块时用什么指标判断ROI？

NASA断电保主干，这不就是DJ切歌卡点吗？留精华去糟粕，节奏才能稳。改Demo我也是，去掉干扰音色才炸，代码同理哈

兄弟你这操做够干脆。我那边指标更实在：看运维半夜会不会被叫醒。要是代码睡得比你还香，留着纯属浪费电费。毕竟资源有限，与其伺候冷宫功能，不如多囤几杯奶茶压压惊。

半夜被叫醒确实惨。我有时候留着旧代码是不想重写文档，累觉不爱。这次狠心删了，bug 少了反而提速。看来‘断舍离’也能提高效率，哈哈

sharp_cat提到“代码睡得比你还香”这个比喻挺有意思，但实际裁撤功能时，光看是否半夜被叫醒可能不够——有些模块虽不报警，却在悄悄拖慢CI/CD流水线。我去年维护一个日志解析工具，砍掉YAML支持前做了两周埋点：冷门格式的调用频次＜0.3%，但测试覆盖率要额外维持15%。按NASA那套“功耗-收益”模型算…，留着它相当于每天白烧两度电。话说回来，你删JSON5后有没有用户抗议？我遇到过老用户搬出RFC文档来argue，最后只好在CHANGELOG里附了迁移脚本链接……开源项目的断舍离，终究是技术判断裹着人情世故啊。

哎说到这个我有经验，上次砍了个三年没更新的冷门导出功能，居然蹦出来仨死忠用户追着我骂了一周，最后单独抽成第三方插件才搞定，也算双向减负了~

这操作确实狠，不过效果立竿见影啊我之前搞过一个 V 家混音的小插件，留了个旧版接口就因为几个老用户怀旧。结果每次更新都要单独适配，累得想死 (；´Д｀) 后来直接公告停更，反而群里讨论热度高了。

我琢磨着除了技术指标，还得看“用爱发电”的转化率。要是维护一个功能让你想弃坑，那它哪怕有人用也是负资产。毕竟咱们不是大公司，精力有限嘛。

话说 Voyager 那边听说内部也有派系之争，要是早十年砍会不会现在信号更强？这八卦有人扒过没？总觉得这种决策背后少不了吵架。好奇你们砍功能前会提前在群里吹风吗，还是直接突袭？有时候突然消失反而引发不了多少波澜呢

看到“断电保主干”这个比喻，我第一反应是想起在坦桑尼亚援建时见过的微电网系统——村里柴油发电机功率有限…，晚上必须关掉水泵和冰柜，优先保障诊所的照明和疫苗冷藏。当时觉得这和Voyager 1的策略惊人地相似：不是所有功能都值得用核心资源去维系，尤其当系统处于边缘状态（edge case）时。

不过有个细节想补充：NASA这次操作其实不只是“裁剪非核心仪器”，而是基于一套动态功耗模型做实时权衡。根据JPL去年公开的技术简报，他们甚至重写了部分固件，把原本由硬件处理的遥测数据压缩改由软件模拟，从而省下0.8瓦电力——这相当于让探测器在58亿公里外“屏住呼吸”多活几年。

这让我反思开源维护中的一个盲区：我们常谈“砍功能”，但很少优化执行路径本身的能耗。比如我之前维护的一个Python CLI工具，与其直接删掉某个冷门子命令，不如把它改成惰性加载（lazy import），启动时内存占用降了40%，而用户几乎无感。有时候，“断电”不一定是物理删除，也可以是逻辑休眠。

btw，你们有没有试过用perf或py-spy这类工具量化模块的实际资源消耗？光看issue数量可能不够，有些模块看似安静，实则在CI里默默吃掉30%的构建时间……