@firelynx 本质就是物美价廉，狼多肉少，至于发车区域与实际人流区域的差异我感觉其实还好。

华北或者江南这种人流密集区可能确实有些中间站在铁路系统内的地位和实际的外出务工人口不一致。
西北方向，内蒙古，山、陕、甘肃、新疆基本上大站就是人多的城市，就是外出人口的主力，人流基本都和血管一样从大城市到本地核心城市再转其它通勤到周边县市。

没候补的时候，你可以抢到票，有了候补反倒抢不到票了，恰恰说明了，候补出来之前买票更并不公平。

优先售卖全程票也并不是候补出来后才新加的，以前也是这规则，没候补的时代如果车次抢手，我也需要多买几站，以保证可以买到任意车厢的票，而不是只抢那一两节区域预留车厢。

你以前可以抢到票是因为你和别人有信息差（更好用的抢票软件）、技术差(更靠近铁路机房的网络线路)、付费差（抢票软件越好用越贵、而且还可以无上限加钱提升抢票软件内的优先级，还有 IDC 机房或者云主机租用费用）。

12306 节假日购票难的本质就是 100 张票 却有 200 个人抢， 最后会有 130 多人在车上，有些人哪怕无票硬上或者买短补全程的方式挤在连接处或者座位底下都得上车。

你之前通过抢票软件抢到票了，对那些用的抢票软件不如你的、加价不如你的、甚至玩不太明白互联网软件的那些人来说更不公平。

各凭本事、弱肉强食的社会达尔文主义我觉得并不能称之为“公平”，毕竟所有人的初始属性并不相同。

在编程里面，一般情况都是包左不包右， 所以我原本是习惯 00:00:00 的方式。

然而在 SQL 最起码 MySQL 中 between and 是左右边界值都包含的， 而我又懒得用 "x >=a 、x<b" 去 替换 "x BETWEEN a and b"

那么最简单的方式就是把 b 改成 23:59:59, 觉得不精确那你就再加精度 23:59:59.999 。

如果你用 java 的话，jdk8 还可以 LocalDate.atTime(LocalTime.Max)

北京，14 年实习 2000 ，15 年毕业转正 5000 。

@wuwuta170 河南的话应该比北京暖和不了太多吧，不过今年冬天确实明显比往年冷很多。

哥们不是北方的吧，或者确实是比较年轻的北京城市居民。
北京都觉得冬季无法生存了，那你想想西北，想想东北，那的人更是咋活，我家内蒙古包头，算西北的现在已经 -12℃~-26 、7℃了。

说白了是你对于轻便舒适的需求大于御寒的需求，觉得特别冷，但又不愿意穿太厚的衣服。而且现在城区里面大家基本可以做到一直呆在温暖区域了，出了地铁就进楼，不会在路上走很久，冷也只是回家的最后一公里或者公交站等车，所以对保暖需求不高。

我小时候冬天都是穿自家做的棉衣棉裤的，那才叫不舒服，自己买棉花封的棉裤那叫一个厚，那叫一个没有人体工学，穿上了蹲下都费劲，上厕所蹲便的时候膝盖窝卡着一大坨只能保持马步的造型。

而现在 一层保暖内衣，一层厚线衣、或者加绒卫衣，然后外面套一个羽绒服，下装也基本是这样三层就基本足够了。
这对于我而言属于冬季舒适的装束了，已经比小时候更舒适更轻薄了。

如果客服说的属实，那么这功能确实就是噱头，没有屁用，单纯忽悠人的效果器。

@weeei 不测都可以知道，肯定会有作用。

比如第一步，沟通约面试的这个环节，就会多出来很多，因为页面的学历筛选项就是，本科、大专，所以以前那些你都不会出现在人家列表里的 HR 也有可能会看到你了。
但接下来 有些 HR 沟通一问是非统招学历，那就 pass 了，不过总会有些 HR 和公司没那么介意，本着既来之则安之的态度和你聊聊然后还可以的就约面试。

假设多出来的这些只要本科的 HR 里面只有 5%的会和非统招学历约面试，那这 5%也是比大专学历的简历多出来的。

父母下岗职工，后面自己按照最低档交的社保，自己交了 15 年养老，目前一个月 1200 左右。

@n18255447846 其实在一线城市这很正常，小地方什么几代人的家业不值钱，但一线你一代人的奋斗居然配和人家几代人的家业一个层次，人家才觉得离谱呢。

北京 500~1000 万房价的小区里还有老太太天天翻垃圾桶找纸箱塑料瓶呢。

（不含贬义，只是说这些人和你们想象中的高素质精英落差大，他们家里没准好几套房子呢，全中国排名都算人中龙凤都不一定比得过他们。
相反我很喜欢这种大爷大妈多的小区，比较有人情味，我把纸箱饮料瓶和其他垃圾分开拿，给他们纸箱之后他们会直接把无用垃圾也从我手里要走帮我扔了，平时小区里也有下棋遛鸟晒太阳聊天的比较有生活气，不像有的打工人小区真的就是睡城，平时公共范围内都没活人）

@mangojiji
他提到的做法就是 controller 入参出参用 VO ，数据库表对应对象用 PO ，中间的 service 或者其它 Job 、Util 、甚至连查表的返回对象和数据库查询参数之类的传输对象都用 DTO 。

因为这些概念是重叠覆盖的。

比如 POJO ， 什么 POJO ，只有属性没有方法的类都算，你提到的所有 O 都属于 POJO 细分后的一种。

什么是 DTO ，传输对象。 只要你用来当参数或者结果集的对象都算 DTO ， 所以 VO,PO,DO,BO 那些乱七八糟的 O 也都是可以算 DTO ，只是阿里发布的许多文档之类的，DTO 单独用来指那些不好归类到 VO ，PO 之类 O 的其它传输对象了。

如果你分层没像阿里或者其它复杂项目架构一样切的非常细，那么你所有不知道该叫什么的都叫 DTO 就行，或者 POJO 不带后缀都可以。


--------------

再接下来说说我的理解

VO： 不论是叫它值对象(Value Object)，还是展示层对象(View Object) 都是一个意思， 指的是展示层专用的、用来包装外部输入、输出的对象。
举个例子，(假设在没有前后端分离的项目中，后端需要校验表单输入)比如用户注册接口参数对象，包含字段 登录名、密码，确认密码、验证码； 确认密码字段对于后续处理没有意义，只在 view 用于校验，所以它可以是一个单独的 VO 对象，重复密码正确后，将这个 VO 中有用的部分复制给 service 层专用的入参对象。

BO：业务对象(Business Object)， 感觉好像只在阿里系规范用的比较深度的项目见过 XxxxBO ，我在小厂混没实际见过。
继续以上一个例子说，注册的 VO 中有价值的部分重新组装的数据传输对象就是 BO ，RegisterBO ，这个 Bo 包含登录名、密码等等，像上一个里提到的验证码，有些人是把它算额外的另一个单独业务处理，在 Controller 中调用其它方法直接校验了，所以这里的 BO 就不包含这个对象，而有些人则是认为验证码也是业务流程的一部分，应该归到这个 BO 里，在这一层处理。

DO：持久化对象，基本就是与各类存储服务库表结构对应的对象，我常见的写法里也没见人加 DO 后缀的， 这个没什么好解释的。
上一个 RegisterBO 中 可能最后会组转成，User 对象、UserExtra 对象、WechatUser 对象、Oauth2User 、SmsLog 等对象分别存储到各自的表里面。


---------
最后：

DDD 那一套还有严格按照阿里发布的规范搞的某些项目可能会区分这么多 O ，划分这么多层， 甚至还有的入参都从 VO 、BO 、DTO 里拆出来，单独叫 Execute 、Query 、RequestParam ，Command 。

但没那么多概念的项目我们实际上不会分那么细，从 Controller 到 Service 不管多少层，除了持久化对象，入参出参都叫 DTO 的项目也有。

把不同层的数据对象拆开最大的好处就是方便项目拆分，独立部署，每个项目只需要依赖自己层的对象，当项目跨部门甚至跨公司的时候方便上游改动时控制影响范围，以及避免下游改动涉及到上游时还得跨部门让别人配合扯皮。
如果整个项目所有部分的所有权都在自己手上时，不分那么细改起来也不麻烦。

@Neillou 目前按钮已经是一块玻璃了，触感靠震动反馈。
我只是不喜欢扫脸而已，要是有屏下指纹配合线性马达那多爽啊。