作为一个前端，一直不明白为什么要晚上发版？

我猜可能跟前端的使用场景和技术特点有关吧？
前端产品是不是跟直接一些，因为大部分效果可以直接看见？
JS 报错之后有些场景不影响使用？只是体验变差，要求低一些的场景被追责的情况少？
“前端是干啥的？就是掉调接口的嘛” （玩笑话，逃。。。）
大部分场景前端不需要对具体交易负责？
OP 是个绝对意义上的技术大佬，vim 写代码不测试一遍过。
请补充

@zhangfeiwudi 我们有时候是两点-四点，因为 0 点往往有 JOB 再跑。
@dapang1221 不不不，恰恰相反，0 点发布搞出问题来了还有时间修复，哪怕有问题第二天老板过来砍人的时候还可以求饶：老板，已经修好了。要是中午发班，刚出问题老板提刀过来了不好解释。哈哈
@weiweiwitch @XSDo 比如一些搞 WMS ，白天发版有问题了，会有几百号人感谢你给了他休息时间。

我个人觉得是一将无能，累死千军。某些公司的领导迷信加班加点，把程序员当耗材用，对于灰度上线有这发自内心的抵触，不了解也不愿意去引入。评论区说什么晚上用户少，出问题容易回滚之类的，有一定道理。但是更大的问题来了，晚上人员状态和心态都不在状态，首先出问题的概率就比较高，这是必然的。
最重要的是，难道上线后不报错就算成功了？ 系统不报错但是数据逻辑有问题怎么办？上线之后谁来观测业务数据？谁来验收？谁来保证有异常第一时间介入？
难道大晚上的上完，回家睡觉，第二天来在发现数据不对，又风风火火地去打补丁修复？如果放在白天灰度上线，上万业务方验收，各方有足够的精力和时间和客观条件去检测
各种系统或者是数据异常，有问题可以第一时间扼杀在萌芽里面。
按你们的逻辑，那些业务遍及全球的企业，白天夜里都有人用，他们的产品是不是不用发布了？

大公司还有灰度发布等措施优化上线操作，但小公司的上线很多是真的要停服务的。

都一样，不然为什么多 nightly 。前端还有缓存，真要回退了也很麻烦

哎，为啥我们公司晚上不能发版、周末不能发版，只让工作时间发版？
有个好处是上线后有问题可以及时处理啊，晚上发版后发现问题，不会大半夜把人 call 起来排查吗？

很多互联网业务就没有人少的时刻

正常，游戏维护不也是大半夜。

因为技术不行

白天更新 有问题=损失钱
半夜更新 有问题=损失了几只 24h oncall 的程序员脑细胞而已

不敢怼上司，搁着发帖算什么？

规范：周五下午 6 点以后不发版
实际：周五晚上 10 点还在改 BUG ，一定要今天发布

前端很难理解，理解这个想法。其实就是怕出问题污染数据。前端随便写，只要请求能发出去格式对就完事了。后端万一出现问题引入了脏数据，大半夜没几个人用恢复起来容易一点，高峰期哪怕只有一条脏数据，也得停机花一段时间看怎么往回滚，一环套一环老难了。

前端可以随时发版吧，后端除非是极其简单的业务变更或者只是新业务没动旧业务，不然都得找个时间窗口小心发版。

因为领导不用参与半夜发版，对领导百利而无一害那就给定了半夜发版了呗，不是什么半夜风险更小，只是因为半夜不用三倍工资，甚至不用给工资。

就算是前端静态资源发版也会影响用户呀。用户正在用，你发版静态资源替换了，用户切换菜单，懒加载的路由资源就找不到了，人肉运维之类的太多了。

因为他们想停机更新，所以选晚上。

他们不想停机的话，凌晨大概率没多少人用，服务器压力小，更新的时候不太容易卡崩掉。

主要是后端吧，前端无所谓

因为我们也曾经尝试过白天发版，但每次最后关头 QA 总能测出新的 bug ，然后开始修，觉得小 bug 应该很快，然后就拖到下午，越后面发现问题越大，QA 在下午又发现了几个 bug ，开发只能硬着头皮修，一直修到晚上，觉得可以发了，QA 做最后一次收尾测试，然后发现 bug 改好了，又出新 bug ，就这么来到凌晨，老板给大家买了宵夜，吃完想着一鼓作气马上结束了可以回家了，结果 bug 还是没修好。最后只能权衡利弊，把一些新出的不是太影响的 bug 放到下一版，然后草草发布。并祈祷发布的版本别出问题，然后拖着疲惫的身体，在公交站，看着马路对面公交站刚下车准备上班的打工人，坐着相反的公交回家。

直接群嘲一下
晚上发版 === 架构师是个废物
淘宝甚至下午 5 点之后不允许发，必须白天发完