Java老兵转型TypeScript为什么我写惯Java觉得TS项目跟屎一样难受一篇拖了半年的反思文。从 Spring 全家桶到 Node/TS 全栈从工程严谨到屎山自由我用一年时间踩完所有坑后写的总结。引子从工程严谨到屎山自由的我我写了五年 Java。Spring Boot Maven MyBatis JUnit 一把梭团队里 50 个微服务井水不犯河水。新人入职第一天就能上手因为结构是被工具强制约束的。去年开始接手一个 TypeScript 全栈项目Node Fastify Vue SQLiteAI 协助开发目标是搭一个智能家居 Agent 平台。一年后代码库长到 4 万多行后端、3 万多行前端我打开 IDE 第一反应是这玩意儿怎么没人管我不是说 TS 不好。我是说TS 项目非常容易烂掉而且烂得没有边界。今天这篇文章我想把这半年的反思写下来给同样从 Java 转型过来的兄弟们提个醒。一、Java 给我免费了什么先把结论摆出来Java 项目的工程感不全是 Java 本身带来的是 Maven Spring JUnit 这一套生态叠加出来的。把同样的约束搬到 TS 上TS 也能写得像样缺了这些约束Java 一样会烂。1. 模块边界是物理隔离Java 项目的目录结构是 Maven 模块parent ├── user-service (一个独立 jar) ├── order-service (一个独立 jar) └── common-utils (一个独立 jar)order-service想import common-utils行先在 pom.xml 里加 dependency。想用user-service的某个内部类编译都过不了——user-service没有把它 export 到 classpath 之外。这是构建系统在保护你。TS 项目呢目录随便取名import任何文件都 OK。packages/backend/src/modules/agent-runtime/index.ts想调packages/backend/src/modules/compensation/index.ts的私有函数没有任何机制拦你。一行import就进去了。这就是为什么我以前觉得 Java 写起来舒适——不是 IDE 智能是架构边界被工具强制执行。2. Package-private 是真的 privateJava 里的class Foo默认是 package-private外部包根本看不见。public class Foo才是给别人用的。TS 里没有这个概念。一个文件export的东西就是公共 API没export的就是公共但没名字。你想我先 export 出去但是只给自己模块用不好意思要么全 export 要么不 export没有中间态。于是 TS 项目里到处是这种代码// modules/memory/index.tsexportconstmemoryKernelnewMemoryKernelService()// 公共单例exportconstplanLibrarynewPlanLibrary()// 公共单例所有人都可以从import { memoryKernel } from ../memory/index.js拿到这个实例然后直接调它内部方法、改它内部状态。没有封装可言。3. DI 容器是默认项Spring 写一个 ServiceServicepublicclassOrderService{privatefinalUserRepositoryuserRepository;publicOrderService(UserRepositoryuserRepository){this.userRepositoryuserRepository;// 构造器注入编译期检查}}新人想绕过去new OrderService()不带依赖编译报错。想 mock 一个依赖测试Mockito 一行代码。TS 项目里我看到的是exportconstorderServicenewOrderService()// 没人传依赖因为没有依赖OrderService内部需要UserRepository那就import { userRepository } from ../user/index.js——直接拿全局单例。测试时怎么 mockvi.mock(../user/index.js)monkey-patch。改了一个文件不知道哪个测试在偷偷 patch 它。4. 测试是文化不是装饰Java 项目里SpringBootTest、WebMvcTest、DataJpaTest是约定俗成的分层测试。一个 Service 没有单元测试PR 直接被 reviewer 打回。TS 项目里我看到的现实200 多个测试5 个 fail 还能 commit很多模块根本没有测试测试覆盖率没人看mock 全靠vi.mock调全局单例测一个模块等于把整个项目都拉起来这不是 TS 的问题是没有人用工程文化的尺子去量 TS 项目。5. 编译期错误 vs 运行时错误Java 编译期就报找不到符号、方法签名不匹配、依赖循环。这些错误在 CI 第一关就拦下来了。TS 也编译但any、as any、ts-ignore、ts-expect-error——全是逃生通道。AI 生成的代码 80% 带anyIDE 黄色波浪线提示从不阻塞构建。我曾在一个 5 万行的 TS 项目里搜// ts-ignore278 处。278 个我知道这里有问题但我懒得修的墓碑。二、TS 项目的屎山进化论我观察到的 TS 项目从 1 万行到 5 万行的演化阶段 11 万行以下看着还不错模块少文件少谁导了谁一眼能看出来测试覆盖率还挺高单例是方便的捷径阶段 22-3 万行开始有味道出现god object一个文件 500-800 行干了 6 件事单例之间的依赖关系变成了一张隐性图没人画过测试开始脆改一个常量5 个测试 failAI 开始介入开发生成大量能跑但是耦合的代码阶段 34 万行以上屎山成型没人敢动核心模块改一行代码要读 20 个文件确认不会爆炸先这样吧成为口头禅新人入职一周还没搞懂模块边界回滚比重构便宜我的项目正好踩在阶段 2-3 之间。最近一次重构我移除了 5 个过度设计的模块auth、approval、compensation、channels、agent-adapter删完立刻单测覆盖率从模糊变成 0——因为这些模块根本就没独立测试过。三、一个真实案例600 行的 god object我项目里有个agent-runtime/index.ts631 行。它干了这些事接收 LLM 流式输出解析 tool calls调 L1 规则引擎匹配调 L2 候选计划检索调 CLI bridge 执行 mi-cli / adb-cli调 mi-cli 高危动作的 approval失败时调 compensation service 建补偿任务调 memory kernel 记录 outcome调 self-enhancement 自我强化一个文件、一个类、9 个职责。这是 Java 里绝对过不了 review 的代码但在 TS 里它能跑。为什么 Java 写不出这种东西因为ServicepublicclassAgentRuntime{// 600 行是不可能过 PMD/SonarQube 的// Cognitive Complexity 阈值默认 15// Class too large 阈值默认 500 行}Java 生态有Checkstyle、PMD、SonarQubeCI 集成硬指标。TS 生态有 ESLint但规则深度差一个量级。四、我现在的解法把 Java 的免费约束搬过来不引新框架引约束。具体做四件事1. ESLint 模块边界硬约束// .eslintrc.json{rules:{no-restricted-imports:[error,{patterns:[{group:[**/modules/*/internal/**,**/modules/*/!(index).ts],message:Only import from modules/*/index.ts}]}]}}这一条规则等价于 Maven 的模块隔离。agent-runtime想偷偷 importcompensation的非 index 文件CI 直接红。2. 单例退役工厂上线// 以前exportconstexecutorGatewaynewExecutorGatewayService()// 现在exportfunctioncreateExecutorGateway(deps:ExecutorGatewayDeps){returnnewExecutorGatewayService(deps)}// 唯一允许实例化的地方composition rootconstcontainerbuildContainer()constexecutorGatewaycreateExecutorGateway({cliBridge:container.cliBridge})测试时constgwcreateExecutorGateway({cliBridge:fakeCliBridge})没有 vi.mock、没有 monkey-patch、依赖显式、测试脆度可控。3. god object 拆开agent-runtime拆成 4 个router.ts意图→路由L1/L2/L3tool-executor.tscli/service 调用plan-runner.tscompiled plan 执行chat-loop.tsLLM 流式对话每个 200 行每个有自己的*.test.ts每个有自己的index.ts公共入口。4. 测试作为模块完整性指标新规则每个模块的index.ts必须至少被一个*.test.ts引用每个公开导出的函数必须有调用测试coverage/报告纳入 PR 检查五、写给同样从 Java 转过来的兄弟们不要把 TS 当 Java 写TS 项目不应该模仿 Java 的重但应该继承 Java 的严。我见过两种极端TS 当 Python 写动态类型、any 满天飞、单例、global stateTS 当 Java 写引入 NestJS、tsyringe、class-validator、class-transformer用 5 个库模拟 Spring都不对。TS 的正确打开方式是用 TypeScript 类型系统当主约束用 ESLint 当 CI 闸门用显式 factory 当 DI 替代品。接受 TS 的开放性是设计选择TS 选择不强制 package-private、不强制循环检测、不强制模块边界——这是给小项目快速迭代留的空间。问题不是 TS 设计错了是项目长大了还没补上约束。AI 生成的代码会加速屎山化我必须说一句得罪人的话LLM 生成的 TS 代码平均耦合度比人写的 Java 高 3 倍。原因很简单——LLM 看到的是文件级的局部最优它不知道你的项目有 4 万行、不知道你想保持模块边界、不知道你想以后拆微服务。用 AI 写 TS 项目必须配套模块边界 lint 规则单测覆盖率门槛god object 静态检查用 ESLint 的 max-lines complexity提交前 review bot自定义否则你会在 3 个月内得到一个AI 写的 5 万行屎山。写在最后我花了半年才接受一个事实TS 项目的工程感不是语言给的是文化给的。Java 之所以舒适是因为整个生态 25 年来建立了工程文化的默认值——Maven 校验、Spring 注入、SonarQube 静态检查、PR 流程规范。TS 也有 ESLint、Prettier、tsc但默认值不一样。如果你不主动设置自己的默认值默认值就是能跑就行。我现在重构项目的第一原则不再是用对库而是**“建好结构”**删掉所有 god object删掉所有单例加 ESLint 边界规则每个模块有独立测试composition root 集中装配这套做完之后才像 Java 时代那么顺手。如果你也是 Java 老兵转型 TS欢迎交流踩坑经验。本文不引战语言只谈工程。TS 是好语言前提是你愿意给它配上工程文化的围栏。
