JS/TS 全栈确实是个大趋势，前后端通吃，是个性价比非常高的路径，可以说是现在年轻创业公司的技术栈首选。加上云原生厂商如 cloudflare, vercel 也都把科技树点在 JS 上，前景看好。

属于事物的一般发展规律了。相关阅读推荐： https://blog.visionarycto.com/p/my-20-year-career-is-technical-debt

有可行性，但只会在有限范围内。TS 的类型收窄，就是静态分析器有限度的做了一点运行时的工作：a) 读懂 if condition; b) 收窄的有效期需要跟踪变量是否在判断后没有改变。类似的，rust 的 lifetime 检查其实也是部分在做运行时的一些 context sensitive 的工作。

所以现在的问题就是，你愿意付出多大的代价维护这个 context ？从实用角度讲，你肯定不能要求静态分析器去追求运行时等效，那性能就没法保障。

咱还拿 TS 类型收窄举例

```ts
if (x === 10) {
x = 10
f(x)
}
```

加上 `x = 10` 就会报错，说明 TS 的实现逻辑就是，老子刚检查完你别动这变量啊，动了我就不保证了。那你说它读的懂 `x === 10` 能不懂 `x = 10` 吗？肯定不能啊，只是它选择不去懂。

思考一下 OP 想要的功能怎么实现，就是要求静态检查器跟踪变量的运行时赋值，除了检查 assignability 还要把 literal value 挨个记住。形如下例会付出多大代价呢：

```
x = 1
f1(x)

x = 2
f2(x)

x = 3
f3(x)
```

考虑性能，backtrace 大概率不会用因为慢，那就用 cache ，赋值几次 cache 几次，就算不考虑循环，赋值这么频繁出现的操作，内存肯定要爆炸。综上，我认为是有理论可行性的，但不经济。

反观类型收窄，是进入 if block 的时候才启用，并且只 cache 一个值，干净又卫生，所以就实现了。

请忽略柠檬精们的发言，你做的事情非常棒！维护过大项目的人都知道，核心技术有多牛逼真不是项目成功的重要标准，最终要的是日复一日的坚持，持续不断的维护打磨各方面的细节。commit chart 初始的几座山仅仅是开始，让项目成功的是后面那条长长的尾巴，以及数量不断增加的 contributors 。长期做好这件事本身比一周肝一万行代码难的多。