CRUD 方法涉及到基础设施，其实是很难 Mock 、Spy 的，基本上都避免不了手写脚本。Spring 的单元测试，只有在结合 Spring Data JPA 的情况下，才能避免大量的数据库脚本处理。或者换句话说，没用 Spring Data JPA ，就别搞涉及到数据库操作的单元测试。

@cubecube #4 它这是要 Mock/Spy 查询数据库的最底层 Bean ，单元放多大都避免不了。

@jaredyam 相对来说，不 Mock/Spy CRUD 方法，换 H2 临时内存数据库+建表、初始化、清理数据库的脚本，可能会更省事点。

玩游戏（主画面，不含 UI 框架）、看视频，不受 DPI 缩放的影响，你只要显卡能带的起 4K 且显示器是 4K ，那么输出就是 4K （但是非**80+级别的显卡一般都带不起来）。而常规使用的话，4K 缩放 200%，可不是 1080P ，它的采样和输出还都是 4K ，只是字体在采样前计算空间占用的时候乘以 2 。假如一个字体默认空间是 100 像素，1080P 它就是 100 像素，4K 不缩放它还是 100 像素，4K 缩放 200%则变成了 200 像素。

一般来说，不打游戏、不做视频、其不搞双屏的话，显示器就是能买多高就买多高。有以上需求的话，就要看 CPU+显卡的性能买显示器了，因为一旦 CPU+显卡带不动高分显示器，就只能低分辨率+拉伸显示，效果比低分显示器要垃圾很多。

改成 @MockBean 外加手动 Spy 的方式，太困难就建议放弃单元测试。存在循环依赖的情况下，做单元测试这种行为就是耍流氓。

@finab #16 只要你将来不转移，公司交的跟个人交的，在个人使用上是没区别的。他俩的区别在后台账户上，公司交的属于地方统筹账户，账户管理方和归属方都是地方，个人交的属于个人账户，账户管理方是地方但归属方是个人（中央）。当你跨区用医保，或者将来回老家要转移养老金的时候，基本上就只能享受个人部分了，因为统筹部分要用就相当于从地方上面往外拿钱，名义上能拿实际上往外拿钱哪有那么容易。

@xiaohundun #20 公积金没统筹，个人部分和公司部分只是个标识区别，实际上没任何区别（民企里面公司交的公积金，基本都是工资里面挪过去的），两部分现在都是随便转（以前不是的，因为这本质上也是从地方上面往外拿钱）。

如果对网络有广泛的基本要求，除了电信、联通，不要办理其他任何宽带。国内宽带只有一个标准，连接 ISP 指定的网站，下载能达速即可。除了电信、联通家大业大，还被人盯着，不敢玩太过，其他 ISP 没有不在上行带宽、网间出口、国际带宽出口、禁止 P2P 等小号带宽的协议上，节省成本的。

楼主这情况，大概率两个原因。一，限制了网间出口带宽，并且没对在 ISP 那里算冷门的 Steam 做缓存，同时 Steam 的国内 CDN 基本在电信、联通那里，导致跟 Steam 服务器直连的带宽就 20kpbs （不过网间出口结算早就没了，这个限制很有可能是以前做得限制忘了去掉）。二，禁用了 torrent 协议，导致你的下载来源只能是 Steam 直连，而这个直连的速度通常也就 20kbps 。

@optional #47 你这是看人老实就少给钱，真要照你这样做预算，公司走不长。预算分多少、分给谁，主要看有多少钱，能带来多少收益。会看成本，但绝对不会像你这样谁便宜就给谁。实际得情况就是公司人力成本是固定的，你要足额缴纳社保，公司就只能从工资上挪。

手机你是拿在手上操作，电脑想想你是怎么操作的。迄今为止，电脑能用感受到震动的方式去操作的，就只有触摸板（平板电脑因为体积问题你也不可能用功能感受到震动的手握方式去操作），这个震动反馈是有的，上面已经有人提到了。

@optional #2 楼主已经把工资、人力成本给明明白白的给列了出来，自己把同样人力成本下的工资数给计算一下。

看下面的描述，楼主说得有问题，这不是端对端加密，而是服务端不保存用户密码。即服务端全加密，且密钥仅在用户手里。国区就别想了，都不用找背后的有关部门，有直接的明文龟腚禁止这样做。实际上，除了欧美这种平民可以用龟腚让 Z 府吃瘪的体制，其他体制下的国家，这个保护都不可能开放。

Android 全系列推送，不管是 FCM 还是厂商自家的，都是直接推送给应用，不是像 IOS 那样只推给独立的“通知中心”。这要求应用常驻（最起码也要开个常驻的后台服务）。这在国内激进的电池策略下，只有白名单中的应用才能正常使用推送。Telegram 这种国外应用就别想了。

不过我还是想说这句话：不狂杀常规应用，怎么保证广告接受应用的稳定。

这玩意，只有内部技术人员才能给出真正的回复。

这种同步，通常来说都是一端发布变更事件（消息），多端消费的方式，需要消息中间件支持上述模式。同步周期，取决于消费端的消费周期。消费的时候，拉取方式跟推送方式都可行，纯推送方式很难处理消费乱序问题，纯拉取方式对消息中间件有极大的性能冲击。这里更可能采取的是推送加拉取混合模式，主处理仍然是拉取，但拉取间隔不是定时轮询，而是仅在接受到远端的推送的时候再去拉取。简单得说，就是推送但只推送“有新内容”而不推送具体的内容，然后由被推送端再主动拉取新内容。如果是这个模式，那么同步策略就是推送。

但是，推送，并不是完全实时的，它要收到客户端的网络环境的影响。理想情况下，客户端永远跟服务器端连接着，那就是实时推送。但实际情况下，推送的间隔完全是不可控的，因为客户端并不会永远跟服务器连接着。Apple 以及标准 Android 推送，为了照顾电池，手机跟推送服务器的连接，不会无脑断开就重连，而是会根据手机电池、网络情况、心跳间隔等自动判断是否要重连，意味着你的手机有可能跟推送服务器断开连接很长时间后手机仍然不去重连。这个间隔不可控，但通常也不会超过半个小时。你这个超过 10 天的情况，应该是应用的 BUG ，或者消息中间件挂了。

你难道不应该先问一下加班时间怎么算吗。晚饭时间不明算的，大概率晚上加班时间也是“自愿加班”，不计入调休或加班费的时间。这种情况，你基本就一个选择，到点下班然后熬一两个月不干活的工资再走人。

要知道，即使是加班加死人的狼性华为，也是给足加班分并且留一个小时给人吃饭的（当然本质上是少算一个小时的加班费）。

@holinhot #7 Spring Cloud 配置中心，面向的是超大系统的运维和运营配置，小系统就不需要这些东西。从业务上说，小系统的配置，以单一配置文件为最优解，为了市场的话可以增加一些后台管理界面来做特定的业务配置。从业务范围上来说，小系统连 Spring Cloud 就不该用。

你要知道，休眠后，按下电源键只是从休眠唤醒的途径之一，不是唯一。而自从 Win10 开启滚动更新模式后，Windows 就加了超多种你禁不掉的自动更新唤醒模式。其中台式机连接电源的情况下，因为没有节能需要，必定会唤醒并自动更新（你正常用得情况下它不敢自动重启更新了）。笔记本断开电源一般不会自动更新，但也有不少人遇见过出差途中因为自动更新被烫伤或者没电的情况。

基本上来说，如果你不完全禁用 Windows 更新，那么就尽量早更新，不然它也就只能在休眠的时候自动更新，从而完全打乱你的休眠节奏。当然台式机可以选择休眠后物理断电，但总有忘记的时候。

这种强制更新，其实并不是资本家的要求，而是干活的开发人员不想维护老版本的要求，目前阶段是无解的。

你可以接受事实损失，但明面上的损失一概不要接受。

艾条拿来做艾灸，是物理治疗的原理。但要是像熏香一样熏房子，那应该是屁用没有。