Bean Validation 只包含了参数检查，这在业务异常中只是极小的一部分，如果你要在整个错误反馈体系中加错误码，那么，不但需要定制一个额外包含 code 的异常类作为所有自定义异常的基类，还需要捕获所有 Java 自身异常和使用到的第三方框架的异常并将其转换成自定义异常。这是吃力不讨好的事。

有一点是需要提醒的，错误码异常反馈方式，虽然是很常见的异常反馈方式，但却是很老，并且基本没啥卵用的异常反馈方式。Java 和 Spring 并没有采用这种体系。

以前没异常体系，只能靠函数返回值来做错误返回，才不得不用错误码来反馈错误信息。而 Java 有了新的 try catch throw 异常处理机制，就提供了更丰富的错误反馈机制。Java 反馈的错误信息，是 java.lang.Throwable 的子类的实例。这是一个对象，必须包含类自身定义（完整类名）和抛出追踪栈（通过 printStackTrace 打印的东西），可选包含 messge 和 localized message 。然后更重要的，java.lang.Throwable 只是一个普通类，开发者可以根据需要任意扩展。

Bean Validation 没有对原生异常体系做过多扩展，所以它也就只能定义 message 。但是，这个是 java.lang.Throwable 的 message ，不是你业务上的 message 。你可以，在定义 Bean Validation 注解的 message 时，定义成业务上的错误码，然后再统一异常处理器中，捕获 Bean Validation 的异常，通过 getMessage 方法提取出业务上的错误码，再做后续转换处理。

首先纠正一点，这是 Spring 使用的 Bean Validation 规范下的 Hibernate Validation 实现，不是 Spring Validation 。然后，这个是验证 Java Bean 的字段的。对应到业务上，它只能验证方法参数的有效性，只能参与统一异常处理，不能替代，也不能侵入。

另外关于错误码和消息的对应关系，你引用的文章的理解都是错误的。如果有了错误码，那么错误消息就只能是错误码的外部展示，它归属于错误码，而不是跟错误码同级别，并不存在一一对应关系。异常上是只需包含 code 的，整个异常处理过程，除了最后的对外显示外，都不需要考虑 message 。message 只需要最终显示时，通过资源文件根据 code 再获取即可，多语言环境下还可以同一个 code 针对不同的语言环境显示不同的 message 。

@catalysia #26 就算是纯水，一次性大剂量喝了也要水中毒。毒性主要看剂量，你那个氯化钠（食盐）一次吃多了是确实要就医的。洗洁精这玩意，没事还是别喝，大量表面活性剂入胃肠，很有可能破坏胃肠的油性结构。

不要追求绝对干净，抛开剂量谈毒性都是刷流氓。表面活性剂一类，对于玻璃、瓷器来说，流动水冲洗一遍，眼睛看不出来有残留，就算洗衣粉都很难有毒了，洗洁精就更不用说了。带皮水果一遍冲。蔬菜看情况，荷叶性质的也是一遍冲，否则就多冲两遍。

另外洗洁精本身就只是个表面活性剂，又不需要像洗衣粉那样强效，所以本身应该也不带多少毒性物质。但是吃喝还是算了，就算没有化学毒，吃了大量的表面活性剂之后，你胃肠的物理结构要遭灭顶之灾。

光改前，估计是 FTTB 方式，光纤到楼，然后网线到户，家里路由器直接 PPPoE 拨号上网，因为最后一段是网线，所以最高 100M 出口。光改后，变成直接光纤到户，光纤到户的话，需要先经过光猫做信号转换然后才能到路由器。

早期光猫只做信号转换，不负责拨号，拨号还是交给路由器做 PPPoE 拨号。后来聪明的中国人发明了智能（宰用户）光猫，让光猫直接拨号外加充当垃圾路由器，免去了用户拨号的麻烦（收缴了用户自行拨号和自行控制顶级网关的能力）。这时候因为顶级网关的控制权不在用户那里，并且要再套一个好点的路由器变成至少两层 NAT ，好多东西是用不了的。不过这个现在卡得不严，像个理由，比如两层 NAT 打不了多人游戏，打客服让技术人员把光猫改成桥接模式（我没搞过，但估计是能远程改，不需要上门），把家里得宽带出口网关，重新转移给路由器可以跟以前一样继续搞了。

然并卵，因为 xx 安全原因，家庭宽带最多分配到动态公网 IP ，并且不超过 48 号必须重新分配一次，还要封掉大部分端口。

这有啥好分享发现的，连最浅显的多线程下载机制都不懂。迅雷下载速度提升的方式其实很有限，多线程、CDN 镜像、P2P 。以迅雷现在的体谅，是支付不了 CDN 镜像的带宽成本，支撑不起来 P2P 的用户量的。你这 1m 变 32m ，背后可能开了 40 个线程，是对下载源的服务器极不负责的行为。

此外，单纯的多线程下载工具，稍微一找就有（当然不能用国内搜索引擎）。

看了半天，原来华为 OD 是华为外包。那就先别找自身原因了，华为外包还搞 6 个月试用期，就特么是个垃圾公司。

正常的华为外包公司，一般用超低基本工资、无福利等低成本方式，让闲人自己走，不会赶人，根本没必要用 6 个月试用期这种手段。我都怀疑这 6 个月试用期，不是为了省那几个月的 20%，而是用“转正后工资就高了”的画饼稳住不想要，但还能在华为那里继续赚两三个月工时的人。

虽然从楼主的项目经验上看，半年这么点，确实是不咋地，但这不是楼主的错。新人是要教的，华为的主管没义务教，但外包公司自身应该负责培训或引导员工自学。其实主管不分配工作的时候，就是主管不想要人了，这时候外包公司应该跟员工谈话，要么找人带，要么让员工自行找出路。非要拖到最后没法拖得时候才让人走，这特么垃圾。

延期一周😓，这是后面不打算要新客户了。就当破财消灾吧。

你这是买断，还用过了，看你情况还是通过第三方买的，退的可能性是零。黑猫那个，不能保证真实性，就算真实了，那也基本上是闹出来的，淘宝和北京环球你好像哪个都闹不过。

还是按一楼所说的，找北京环境弄延期吧。不可抗力原因导致的无法使用，这个不管是你不能去，还是商家没法开，从市场运营上来说，都该延期（延期对商家其实没啥损失，反而能收到更好的宣传效果）。

十几种还不算多，如果能做成枚举的话，switch 枚举并无不妥。如果太多做不成枚举，或者稍微有那么一两个变异的分支，用 if else 也不丢人。你要知道，你后面的处理是分发不同方法，那么就算有 50 个，代码行也就 150 行，不多。

这里的重点，还是你的消息类型的命名规则。消息类型如果是依次罗列命名，超过 10 个就麻烦，超过 20 个就没法用了。基本上，超过 20 个类型，就该考虑对消息类型的名称进行归纳分级。如果消息类型有良好的命名规则，消息分发可能就不需要 swtich 、if else 了，十几行代码就能搞定。

在域名组织架构上，子域名是主域名的衍生（可对应子公司 /事业部）而非下级（子部门）。maps.google.com 跟 google.com 是平级的两个域名，google.com/maps 则是 google.com 域下面的一个资源。这是互联网自诞生之初就存在的规范，本来谷歌对这种传统规范是带头不遵守的，可能上次搞隐藏 www 的时候犯抽了。

大致看了一下谷歌的产品，目前，搜索（ google.com/webhp ）、图片、地图不是独子域名，其他的是。这基本意味着，搜索、图片、地图三个服务背后是一个团队，其他产品则是独立团队。砍 maps.google.com 的时候，估计就是地图开发团队被合并到搜索团队的时候。

回车、换行是对应打字机的，不是文字排版。文字排版上的概念是段落、行。

Word 里面回车换段落，Shift+回车手动换行，段落内自动换行。

HTML 里面<p></p>对应段落，</br>对应手动换行，段落内自动换行。

Markdown 没有唯一标准，用得比较广泛的标准是：用一个空行来换段落，用行尾的两个或以上的空格来手动换行，段落内自动换行。

首先，几十 G 大小的 3A 游戏，里面占绝大多说比重的是美术资源，实际的代码量可能不到 1G 。然后，软件的成本主要是看开发的人力成本，而这个人力成本，跟代码量，没有必然的线性关系。

玩多了正版老游戏，你就会发现，除了极个别的游戏外，不管多好的游戏，一旦最终版 /决定版 /年度版发售，或者季票上的所有 DLC 都推出了，那是一丁点的维护都不可能再有了，那时候还没解决的 BUG ，将永远流传下去。别看一个游戏几十上百 G ，但是其软件开发生命周期，通常就 2 到 5 年。而一个能卖钱的工具软件，哪怕它只有几十 M ，那也动辄都是十几年的生命周期。同样是千人团队开发，3A 游戏跟 Adobe 套件的成本，是不一样的。

以上成本分配，是由需求决定的，工具软件是刚需且是长期需求，才会有那么长的生命周期和那么大的成本投入。（电子）游戏是激情需求，注定了它只能是即抛性的，不会给大成本或者长期成本投入。那些妄图做长线运营的 3A 游戏，注定一地鸡毛，要么死（比如“要做十年的光环 6”），要么穷（网游 GW2 、FF14 ），要么司马（暴雪）。

@BeforeTooLate #16 不是只有银行明面叫的理财才是理财，“手上现金可以随时置换其他资源”，这也是理财。你的理解，本质上还是“理财能保证年华大于房贷就不提前还”。不过，要达到你想法的前提是：置换其他资源，以及加上存款抵抗风险的等效收益后，收益率要大于房贷。

说得这些，要是都做到了，那就是一个比老板还老板的老板，干嘛还要打工。

打工人的事，就不要搞那么复杂。劳动法要是能执行好，被裁根本不是事。否则，躺着不是最好方案但是是最优解。

虽然但是，人体工学坐姿，手臂是要自然下垂，不能靠扶手支撑的，最多价格掌托避免手掌下翻。另一方面，手肘放到扶手上，会影响手掌的移动幅度，要么没法顺利移动，要么导致一些肌肉劳损。

@HaoBaiCai #24 这公司不一定烂，但绝对不好。

OP ，今年 4 月，发去年 4 月到今年 3 月的年终，跟今年 4 月，发去年 1 月到今年 1 月的年终，这是两码事。