nodejs 方案不选用的理由+1 ？

我这台 6 年前的 y50-70 搞黑苹果，用得正爽

顺手分享下今天遇到的一个问题，wps 中 excel 导出网页不能选择单个 sheet 导出，导出所有 sheet 的网页会使用框架，然后无法在 chrome 打开

测试一下喇叭有无破音，有朋友的 mbp 尝试了一下喇叭，发现大声一点就有一边的喇叭是破音的。

小孩子不做选择，开会用 14 ，坐下来就用 16 ？

没那么严重吧，平时来回切去 note 或者电话本搬一些发票信息，都没试过重启啊，6s 钉子户

所以，酒店系统能恰个外包？

所谓的转，会有明显感觉？感觉负责事情多的后端，慢慢就变成了产品经理？

之前参与过一次讨论，确实不只是 Ramdom 那么简单。主要是不能确定抽奖总次数（总人数）。
一般简单的需求只是提出了中奖概率：一等奖中奖率 1%，二等 3%，三等 5%，为了方便讨论，姑且再简单化每个奖项奖品数量为 1 。
然后大多数人一上来的写法就是 random1~100 ，然后得出指定的一个或者多个的数，来做中奖判断。
实际上这种简单模型，只遵循了理论上的中奖率，没有符合到实际需求。因为中奖变得“先到先得”更为重要了（可以写个模拟抽奖 demo 测试一下），但实际上一场抽奖活动更多的是希望吸引更多的人流，并不想活动开了半天大奖全部抽完。
所以当时我盲猜两种做法：1 极度调低实际的中奖率，配合活动结束时间稍微调整让奖品都能送出； 2 也是要配合活动时间定时定量动态调整奖品中奖率。

我理解的提议是：不能 new 定义的父类，只能 new 其子类。那就在父类的构造函数直接抛错？（子类不调用父类构造函数）

我上一个项目就是这么搞优化的

但并不是随便找个项目就能这么做，是刻意的，以教学为目标的 github 项目

还有一个建议是，与其耗时间证明那么多，不如同时般地，花更多精力着手开发新功能，新界面，然后走一条防抄袭的路。东西可以抄，但思想抄不了。

markdown 的发明，只是创立和统一了一种新写法，可惜没有把渲染也统一起来。。。