@twofox #5 另外，Oracle Java 所谓的 LTS 版本，本质上只是半年滚动更新版本额外加了两年半的 BUG 修复支持，并不是精心准备的年度大版本，是个假的 LTS 。

@twofox #5 Java8 支持早就到期了，现在是 OpenJDK 社区在做社区支持。

Java 9 开始，施行滚动更新策略，半年一版本，到期即停止维护，且后续升级不再考虑向后兼容。这是万年 Java 8 的主要原因。

友情提示：常规的函数式接口，只能用 Lamba ，或者匿名内部类初始化，意味着该类型的变量，只能是方法内部的局部变量。不用违反常理的黑科技，压根就不能复用 Function 。

对于使用函数式接口作为参数的方法，它期望的是即时生成的匿名函数,而不是事先做好的公共组件。这种情况下，写下 func.get()的时候，它连 func 是谁都不知道，怎么可能让去找原始 Function 的代码。

函数式接口，是给你写即时匿名 Lamda 函数，不是用来定义公共函数的。你们公司这行为，明显是用错了。

影响月度收入的，有整体经济水平，有劳资双方关系，但没有工时。工资跟工时的关系是，先确定工资，后确定工时，反过来没影响。所以压根就不需要假如，无论如何结果都是「不能」，并且不管你是否愿意。

如果你不纠结 80%，那也不用做这种空的假如。去看看富士康的工资构成就知道了，富士康是不强制加班的。

以开源项目为参照，生成自己的项目，随后闭源，这种只拿不反馈的行为，本来就是违背开源精神的。这还不行，还要打很多小动作，将已经闭源的项目，伪装成开源项目来帮推广。这种行为，怎么会有那么多人洗。

@itsnull 原始 immersive-translate 只开发了 1 个月，这看似原始 immersive-translate 并没有为新 immersive-translate 提供多少，但实际上不然。常理上，next-xxx 自然继承 xxx 的影响力。如果 next-xxx 反过来要顶替 xxx 的名字，那基本上说明 next 很失败。虽然你很看不起这个神圣的只开发了一个月的原始 immersive-translate ，但作者顶替名字的行为，已经说明了原始 immersive-translate 就是比新的 immersive-translate 神圣。

就算给你个退一步的假设，next-immersive-translate 就是比 immersive-translate 牛，那你也不能顶了人家的名字。这不是「老大生瘸了，就埋了老大，让老二顶上老大的名字」，因为原始 immersive-translate 是以 MPL-2.0 协议 fork 出来的，其作者并不对代码具备完全所有权。这个行为，相当于：
「李龙」拜师郭德纲，被赐名「李云龙」，短一个月即自去，半年后再出山，但不名「李龙」而名「李云龙」，众人异其名，曰，「师仅月而无所为，吾自学之，何以阻我用云字]。欺师灭祖的玩意。

@wonderfulcxm #26 竞业补偿，允许晚 3 个月发放。但是，竞业协议不会因任何一方的违约而自动失效，公司超过 3 个月没发放也仅仅是发放失约，不表示协议自动失效。要想提前失效已经启动的竞业协议，必须是双方一致协商，或者法院判决书。如果你真得签了自动启动，并且违约赔偿高于竞业补偿（这个很重要）的竞业协议，那你说得情况是绝对可行的。所以别啥协议都跟公司无脑签。

@marcong95 #12 竞业协议可以强制启动，也允许自动启动，但不会默认启动，具体要看你协议是咋签的。此外，如果竞业协议当中明显不合理的条款，例如扩大化的职能范围，“包括但不限于”的竞业公司，是可能被法院判定条款无效从而导致竞业协议无法启动的。

10010 的没办法，你只能冒着不接受正常通知，例如流量超出的风险，直接屏蔽 10010 。

@ersic #10

除了手机这种超日常能原地外包的，一般电子产品售后都是寄回原厂修好再寄回来，越是大品牌越这样。大品牌的好处是会提供以换代修——前提是还没被薅秃。

友情提示，滴滴被罚是因为把数据往外面搞（不管是有意还是无意），不是搜集数据。国内要是能因为搜集数据被重罚，那太阳得打西边出来。

@hjw45611 #20
@32 #55
殷商经常迁都，只是后期才稳定在禹贡黄河（现在的安阳，是那时候的黄河北岸）以北到太行山之间，纣王时期殷商的核心地区其实是河北。“宋”，也就是现在的河南商丘，只是成汤时候的殷商中心。

当然，幽燕之南的河北，跟河南，是一个口音。

用二硫化硒或者硫磺皂，都只治标。要治本还是的靠自身：不熬夜，除了睡觉外不在床上躺，用温水勤洗脸洗头（重点是不要偷懒去用什么一次保七天的洗护用品）

QQ 浏览器 iOS 版，跟 iOS 没关系。这白白被浪费这么长时间。

对于楼主本身，11 楼 whooami 的回复就足够了。

然后从技术上面说一下。

第一个层面，假如只是不想要 @Autowired ，但是还保留成员变量定义。那么你是必须留着 @Autowired 的，因为并不是所有的成员变量都是自动注入的（尤其是有状态 Bean 的时候）且没有什么好的约定能代替配置来区分它们，所以你必须显式的声明它要被自动注入。当然也不是没有替代措施，当你定义了构造器的时候，那就有了通过构造器自动注入的约定，这时候就可以省略掉 @Autowired 这个显式声明。构造器自动注入，也是 Spring 官方推荐的自动注入方式，但是构造器注入的可读性，不如直接在成员变量上声明 @Autowired 好。

在第一个层面，恰恰相反，必要的显式声明 @Autowired 不是地狱，隐式强制对 Bean 的所有成员变量做自动注入，才是地狱。

第二个层面，假如是连成员变量定义都不想定义，继承 baseService 就能自动引入所有 Bean 。这本质上相当于把所有 Bean 整合成同一个类型了，已经将 Java 返祖成原始的 C 了，根本无法作出技术回复。