hallDrawnel

vscode

正确的做法就是就地判断 error ，当场决定是否要处理。相比抛出异常，有了更合理的处理时机——在错误发生的地方，持有错误发生的上下文信息，可以自由地编写针对性的处理逻辑；而统一的异常处理节点已经丢失了错误发生的上下文信息。赞同 frodez 的说法，统一的逻辑往往就会变得既不方便也不正确。

panic 仅仅应该用在整个程序已经无法继续运行的时候，对于业务逻辑来说很少有这种情况。

产品用这个吧，输出到我们这纸和笔画一下架构就行了。

直接用网页画，pyqt 也不好用。

@pepesii 确实是这样的。遗憾的是由于容器化等让服务拆分的代价小了很多，导致很多不合格的开发者害怕对现有服务做迭代，随意拆分导致整个系统乱成一团。

有 devops 来做这些事情，然后做成自动化的流水线。

看你接触的工程有多大，我现在 1T 差不多够用。

字节就是这样啊

会，我们的业务后台和前台就是同一套账号体系，因为需要给到非厂内人员使用，比如外包运营，第三方公司的各种人员等不可能给他们公司内部的账号。但内部还是有另外一套全公司级别的账号体系打通，可以做权限更大的事情。