已经开的发票还能改，税务局这么好说话的吗

不使用字段上的 @Autowired 的唯一好处是，去掉 Spring 后你仍然可以手动注入。这在 Spring 几乎不可能被去掉的前提下，属于过度设计。而且还是很严重那种，因为替代方式都有问题：
隐式构造器依赖注入（就是说得 private final + @RequiredArgsConstructor ）需要有强的团队约定否则就严重影响代码可读性。
构造器注入容易出问题，而且参数多了会影响可读性
Setter 注入器因为 lombok 尚不能很好的支持，没法用。

把主页和新标签页，设置为空白页（ about:blank ）,不让设置就换浏览器。

严格意义上来说，swagger 的接口定义是要自己写 yaml ，跟你后端定义的对象无关的。能够自动根据 Java 类生成 Swagger 接口定义的，是 Springfox-swagger 插件。而这个插件，是允许你通过注解的方式用自己的定义覆盖默认定于一的，所以及时使用 Map 仍然能够不影响 swagger 这类的接口定义，只是需要多做一些注解 /注释性的工作。

当然，用 Map 不影响，不是鼓励 Map ，首选仍然是特定的类。楼主这里推荐用 Map ，是因为它返回内容当中的字段是不固定的，有可能还是前端要啥后端返回啥，这时候没法定义特定的类了（或者说定义的类就用一次，太浪费），用 Map + 注释 /注解会更省事。

这个警告的原因，不是强制类型转换，而是 List 到 List<String> 加泛型。

如果你需要的是 List 而不是 List<String> 那么用 List<?> 或 List<Object> 代替 List<String>。

如果你需要的就是 List<String> ，并且确定返回的就是 List<String>，那么 @SuppressWarnings("unchecked") 就是最优解。

如果你不能 100% 确定返回的是 List<String>，那么还得用 List<?> 或 List<Object> 接受变量，然后 if (get(i) instanceof String){...} else {...}

网关 192.168.64.1 ，是从你的宿主机上虚拟的网关，跟真是路由器网关可能会有区别，具体不能只看虚拟机上的网络配置，要看宿主机上的虚拟化配置。

连公积金个人部分那点小钱都想昧掉，你觉得还有啥是不能昧掉的。

@NeoZephyr 先拿 Thread.sleep 来说，sleep 100 毫秒，只是告诉线程调度者要休眠 100 毫秒，但线程调度者并不会严格按照 100 毫秒去休眠，而是首先照顾自身的调度机制，这样就会产生误差。在线程调度级别，这个误差很小，几乎可以忽略。到了时间轮上，误差也是这么来的，误差的大小取决于时间轮的调度配置。配的调度间隔小，误差就小，但轮询消耗高。配置的调度间隔大，误差就大，但轮询消耗小。

时间轮的误差大不大，取决于怎么配置，linux 的是操作系统级别任务，配的误差就小。对于现实业务，误差是允许很多大的，比如说“一天后自动退款”，你给误差 1 小时甚至 12 小时都允许。这时候就可以照顾性能，给时间轮配置大的调度间隔。

放在普通移动上就会特别区分质量跟重力，不知道为啥转动上就不再可以区分转动惯量跟转动力矩了。

@yanqiyu #26 质量 /惯性 /转动惯量，本身不影响功率，它是影响物体移动 /转动时候要施加的力 /力矩，进而影响功 /功率

我是没发现 JDK 有精确控制时钟（基于精确时钟触发操作，不是获取精确时钟刻度）的 API ，考虑到 Java 运行在 JVM 而不是 OS 上，JDK 要没这 API ，第三方框架也做不了。

时间轮那个，原本就不是精确延迟时间，其实毫秒级别都已经过了，大量任务跑起来，误差都是上分钟级别的。选择毫秒那是因为在不用时钟的情况下 Java 能读取的时间刻度的单位最低就到毫秒。

预算够买今年的旗舰，不够就买去年、前年的，都能管你用上好几年。

三星，必须是旗舰级，备好梯子，买港行，或者买国航刷港版

@darksail
@yanqiyu
应该是转动力矩不一样，惯量不直接影响功率。

共享 GPU 内存是动态内存，包含 GPU 独占内存和普通内存，0.3/7.9 GB ，前面的是实际使用，后面的是上限。GPU 独占内存，要看内存里面的 “为硬件保留的内存”。

GPU 独占内存和共享内存，只要分配完成，性能是一摸一样的。区别就是共享内存的动态分配过程，会对性能有影响。

@zhujyxs0831 #93 不考虑货币的流通价值，而只考虑货币的字面数字价值，再想想到底谁傻。想不通是容易变成被卖了还帮人数钱的韭菜的。
@AoEiuV020CN 总结一下这种手段对公司的好处：
第一，就是之前说的，靠工资代扣和统筹结算的时间差增加流通资金，或者直接昧掉这部分钱。不过这就对钱少的小公司有用，对于大公司增加的流通很有限。
第二，看工资条最直观，假如公积金缴纳额从 300*2 变成 900*2：你的工资条会从“公积金扣款 300”，变成“公积金 -300 、其他 -1200”；公司在你这里的账本收支部分会从“公积金 -300 （代缴个人） - 300 （公司支出）”，变成“公积金 -900 （代缴个人） - 900 （公司支出）、从员工回收 +1200”。你自己的账面，结合公积金账户，账面收支平衡，实际上的收益取决于你的公积金账户能怎么用——能随时取出来用那就是完全正收益，否则就是用流通价值换减税。对于公司部分，收支从原来的“公积金 -300”，变成了“从员工回收 + 1200 、公积金 -900”，单看数字都是 -300 ，但是公积金支出变大了，这对公司的总税务是有益的（具体怎么有益我就不直到了，要专业财务来分析）。

公积金如果你只存不花，那基本相当于把现金免息借了出去（公积金是有利息的，但低到可以忽略），所以公积金避税的好处并很有限。以前起征点低的时候，好处还很明显，现在起征点高了，好处不明显了。

但是你们公司能找你三次谈，我觉得你有必要查查你的社保和公积金余额。因为这种避税对公司是没有任何好处的，除非它一遍扣你社保和公积金，另一边不往社保局和公积金中心按时划款。

不贴代码，能看个卵卵。看这情形，很有可能你接口调用弄得单例或共享 Bean ，耗内存的变量用了没释放。

这不是技术问题，是选择问题。要求严格的话就单独弄一个实体来对应历史手机号 /邮箱，没要求的话就不保留历史直接覆盖，可以偷懒（或者不给设计时间）的话，就加列保存最近一次历史。