对不起，对于应用开发者来讲， 单从语言的表述能力和抽象能力，TypeScript 都是其他语言望尘莫及的。

这都还没提及技术生态体系，研发成本和培训难度

你是 VC 还是年轻人。。

八股习题而已

对于现在的 12306 买到票完全属于与网络环境相关的随机事件。

现在任何付费刷票，都属于祖传秘方包生男，无效退全款

不行，模型能力差事

何不食肉糜
不仅提前还贷，还要自己交北京的社保。。。

再加一个类型参数，现场合并。。。
真拧巴。。。

我解开了


interface NumO {
[k: string]: number;
}

type WithID<T> = {
id: string;
} & T;
type WTF = WithID<NumO>;

const v = {
id: 'wtf'
} as WTF;

// OK
v.id = 'str';
v.a = 3;
v.b = 4;
// Not OK
v.c = 'sr';

还真是，等一个答案

```typescript
interface wtf {
id: string;
[k: string]: number;
}

```

有什么需要跳版本号的，直接写个定时任务每天跳一下，一年 365 个更新，你就满意了，这个项目就 maintained 了？

很多项目开发都已经完成了，再改就画蛇添足了，不需要再更新

即便在群里也不一定看群，别人的关注点和你是不一样的，每个人操心不一样的事情，不能假设别人和你完全接受了一样的信息，要是和你关注的东西完全一样的话还要你干啥呢

为了不受制于人我直接买了熔接机，练了一手熔接

光纤入户现在一般不熔接，都用冷接。只有纤芯多才会考虑熔接，市价 10 块一芯，一般 FTTH 只有一芯，大部分冷接。

一些同学对公平缺乏想象力。

一般来讲公平可以分为程序公平和结果公平。
现代的公平实践一般由程序公平为起点，兼顾结果公平。


从购票程序上 12306 分为线下、线上、电话三种渠道，按照内部实现机制对车票实行随意分配，对所有的用户同等地不负责任，可以认为实现了程序公平。

针对铁路运输的特点，相对冷门的目的地也受到了一定的保护，获得了一定程度的资源保留，可以认为考虑了结果公平。

但是。
还有一种可能，考虑历史的公平。
所有的人同等地享受乘坐火车的权利，有时为了其他人的结果公平，一部分人没有买到票，这种对权利的让渡不应该无限制地发生，完全可以综合历史购票结果，在进行资源分配时进行加权或者补偿。

12306 从来都是不负责任随意卖票的，
它的票总能卖得出去，对他是没差的，到底有没有人没买到票，多少人没买到票，没买到票的都是什么人，它不关心。


它抢票阶段负载均衡的原理是把卖票权限分发到各个节点，各节点各卖各的，但你访问到哪个节点是随机的，是你的网络环境决定的。
等于你抢不抢得到票是和你的网络环境相关的一个随机结果。

候补算是给这种任意妄为打一个小补丁，确保第一次随机卖出的票被退掉之后分发给有需要的人，从而减轻刷票压力

自始至终 12306 的目标不是为了你能买到票，而是为了它的票能卖出去，并且减少流量负载。

一塌糊涂