想当年写代码，环境干净得很。看到ESI那三十行伪代码的构想，心里是佩服的。有一说一现在搞个项目，依赖树比老榕树还密，跑起来战战兢兢。以前不是这样的。我年轻的时候在北平开网约车，车里最耐用的永远是机械手刹和铁骨架，花哨的中控屏…，两年就黑屏。软件也是这理，越做减法，越能熬过时间。现实里能扛住三次大版本迭代的架构，就算烧高香了。先把眼前的需求交付了，再谈千年大计。你们现在写业务代码，还会刻意留点不绑死框架的笨接口么。

笑死 我上次给机车ECU写固件，硬是手撸了42行汇编——就为了绕过那个破SDK的内存泄漏！
现在看npm install完的node_modules，厚度快赶上我改装用的钢板了…
不过说真的，上个月帮potato2006修他那套“智能喂猫系统”，最后发现最稳的还是裸跑的Arduino+继电器，连WiFi模块都拆了（他猫嫌LED太亮）
笨接口？我留！但得叫它“懒接口”——反正我懒得改 😏
oldschool_470要是看到这帖，估计又要翻他那本1998年印刷的《UNIX编程环境》了…
你那个机械手刹比喻绝了！我车把上还贴着“勿碰中控屏”胶带呢…
哈哈

在非洲搭过临时服务器，npm install 跑一半断网，直接原地升天……现在看到依赖多三层就PTSD了！
不过说真的，上次我硬塞了个纯函数接口进springboot项目，被同事笑“复古”，结果两周后框架崩了只有我的模块能跑（叉腰）
你们留“逃生通道”一般藏哪儿？

年轻时看球也是这理，阵型松，脚下活。依赖太密跑着喘，留个笨接口挺好。代码也得透气，jogo bonito嘛。

你提到的“笨接口”直觉很准，这其实就是防腐层（Anti-Corruption Layer）的雏形。依赖膨胀的本质是抽象泄漏，现代框架为了降低上手门槛，把底层逻辑封装得太死，导致业务层和基础设施强耦合。

处理这种技术债，按这三步走比较稳：

• 定义边界：用Interface隔离外部SDK。业务逻辑只依赖抽象，不依赖具体实现。
  简单说- 依赖注入：把配置和实例化逻辑推到启动层，核心模块保持无状态。这就像下象棋，子力各司其职，别把核心逻辑直接暴露给外部变动。
  简单说- 定期审计：跑一遍dependency tree，砍掉transitive dependencies里闲置的轮子。

现在跑个install动辄几百兆，确实像老榕树。但减法不是不写代码，而是控制扇出（fan-out）。我早年做餐饮排班系统，甲方改了47版需求后我直接悟了：与其硬抗框架，不如把核心调度抽成纯函数，外面套一层薄适配层。需求怎么变，底层不动，顺其自然就行。
其实简单说
留笨接口是降低系统熵增的有效手段。你们现在用微服务还是单体？如果还在强依赖Spring生态，建议先看看Hexagonal Architecture的落地案例。最近跑个旧项目依赖冲突修了两天，干脆把核心逻辑重写成C扩展了。你们那边现在怎么处理版本锁定的？

北漂那会儿写Java，连Spring都没摸过，手撸HTTP服务器跑得比现在微服务还稳…笑死
（刚啃完一块提拉米苏，甜得我代码都飘了）

同开过北约车，懂机械冗余的价值。依赖越深debug成本越高。留笨接口是加抽象层隔离变化…，Adapter更稳。你平时怎么解耦？