IT 行业含括太多了..
另外转行的我见的多，但是能接受转行后工资比转行前工资低，并能坚持下去的，不是很多.

@woaiqiqi #3 软件优化和 CPU 有关系，X86 指令集 都能运行，
就好比 INTEL 支持 AVX512，但 AMD 不支持，
如果使用的软件有针对优化使用到 AVX512 指令集，那速度是比没有该指令集的 AMD 快。
但前提是要看具体什么软件是否使用了该指令......
当然也存在负优化的...反正这个怎么说呢，
其实现在这个年代，日常使用优化不优化体验都差不多.....

TP 我记得是有做缓存的；
php opcache 也是有做缓存的；

@xtx
之前有人评测过，刹车测试连续刹车 10 次，最终稳定的结果是 38 米(100km->0)；
这种测试其实是用力把刹车踩到底(因为我知道是在测试刹车)
但车主的真实情况可能包含预判性，
即：我可能只需要减低到 XX 即可，所以不用力踩刹车..
或 常开电车的人，平时在市区由于都是低速驾驶，抬起电板就减速了，根本不需要踩刹车或轻踩即可，照成发生事故时根本没反应过来。

当然以上纯属猜测。
不过有一点是，特斯拉说明书 /提车课堂上有说过，遇到紧急情况可长按 P 进行紧急制动。
明显驾驶人是没做这一步的。

md3 就是过于精简，很多人习惯还没跟上，所以随便把车给别人开，对大家都不负责。

多次报道的刹车事故就是这样，
燃油车一般都有手刹，脚刹失灵的情况下，可以通过多次拉动手刹控制方向盘进行减速。
但特斯拉没了手刹，取而代之的是操纵杆上的紧急制动按钮。

如果是答题的话，我觉得 1 是最佳的选择。
如果是实际应用的话，我觉得 2 是最好的选择。

当哪一天规则改变的时候，2 的扩展代价相对低。

@chengxiao #105 群辉能装 kde 界面吗?
我看了下官方那，支持 linux，但需要 kde 界面才能运行...
实在不行你可以群辉->虚拟 win7 挖。

1 、注册认证服务号
2 、开通信息通知（欠费、支付提醒）

流程：
1 、业务服务器下午检查欠费信息(时间你自己定)->通过模板信息发送欠费通知，链接到支付页面。
2 、支付页面通过参数获取用户信息和欠款费用，参数是否加密等自己考虑；
3 、调用官方的支付 sdk，完成支付。（ java 生成与交易 ID，签名等信息，返回给支付 SDK，SDK 直接拉起即可）。
------前端完成------
支付成功信息是异步回调的，
*1 支付后微信发送支付信息到你生成与交易 ID 时候填入的通知地址中，
*2 通知地址自行执行充值完毕的业务逻辑。

这样就完成了。
你没公网 IP 的话就自己想办法打洞之类，反正让微信的通知能送达即可。
另外 accesstoken 我记得是要加白名单 IP 的，具体不确定，你自己看看文档；

话说现在新版本支付 API 接口我还没看过，上面的是基于旧版本的。
还有公众号模板信息听说要关闭了，不知道能否使用，
如果不能使用你直接去服务号那添加个菜单欠费缴款即可。

其实也不是说国内的就爱占小便宜...
哪里的人都会占小便宜，
国内只是一部分人以占小便宜为荣，占便宜后到处说，这样就导致另一部分人感觉吃亏，然后就一起.....

另外 iphone 电池我不清楚，mac 屏幕就算买了 ac 换屏也要几百吧？没事为何要弄坏区换呢.......
不过我自己手机华为 m30p 之前买了延保，快到期的时候自己真的想过摔坏屏幕，然后换新，但是懒惰制止了我的行为....

好奇问问，信用卡延保 是什么来的？

华为，个人备案了 4 个域名都通过了....
之前腾讯云工单系统，有被拦截过外呼号码，
原因是开启了移动的防高频电话骚扰功能，但是每次拦截都会附带一条信息提醒.....
如果你手机完完全全没提醒，建议检查下黑名单，如果黑名单有这个号码，则完全不提醒。

目标：商品类别。
逻辑：高于 X 元每分钟自动减少 Y 元。
不确定因素：
商品价格扣减 Y 元后是否允许高于 X 元？
每分钟自动降价是否有个价格 /时间阈值？

多一个条件和少一个条件做法都不一样，建议先确定好需求，再想方法。

@martianyi
我怕拍完了你会问我
为什么你已经联网了还需要拨号。
你任务栏里的飞机图标是什么黑科技吗。
你为什么打开的网站我之前都没看过。
你家人知道你会爬墙吗

搞不好到时候你就把我送进去了，
未经报备使用这些属于违法行为，已经抓了几个人了。

如果你不需要真实的画面，
那其实你也没必要上来收集素材啊，
随便找个脚本，让蔡*坤拍就好了，蔡徐*毕竟挺能演的

@bleepbloop
>存储过程也能拆吧，DBA 和后端配合好就行啊。
存储过程再怎么拆也是在同一台数据库主机上运行吧？
业务代码可以拆分为单个服务，在不同节点上运行。

>于你说的业务代码可以熔断，使用存储过程的时候业务代码为什么做不到熔断？
存储过程中如果如果跑复杂逻辑处理，导致数据库主机 CPU/IO 跑满了的时候，整个 DB 基本就挂了，业务熔断和不熔断意义已经不大了。
但是如果把业务处理流程交给业务代码进行，某部分的处理流程挂起时，通过熔断的方式，还能避免其余业务同时被挂起。

加上#51 所提到的，当你需要使用数组 map 之类的，存储过程中只能通过临时表来解决，临时表的创建 /销毁等开销 无疑也是增加了数据库的负担吧？

>阿里说的不一定就是对的吧？维护移植性不好这一点我也没看明白。
其实很多东西没对错只有是否适合，阿里说的也仅仅是对于他们。对我们只有参考性。
维护不好维护这点应该好理解吧，业务代码我可以通过热重载来进行更新。也可以通过基于版本号访问来进行。我需要改动的只有业务代码这块；
如果通过存储过程，如何实现这部分？
mysql 集群场景下，存储过程好像不会自动分发吧？(这个我没把握，不清楚。

然后移植性不好这点，就更容易理解了吧？
比方去 IOE，当初如果存储过程是通过 oracle 编写的，
数据库换为 MYSQL，存储过程是否需要做兼容 /重写？
但是业务代码中，只要 SQL 代码不使用某数据库的特性来进行，数据库怎么换(常规数据库)，基本业务代码部分也不需要修改。


当然了，上述提到的问题不全面，也有可能并非所有项目都会遇到这种场景，
但是该发生的还是会发生，既然存在缺点，优点又不太明显，为何不放弃这种做法呢？
-------------------------------------------------
另外我看过的一般都是.net 的 C/S 架构会使用 sqlserver 的函数进行一堆业务处理居多。
C/S 架构不是我强项我不讨论，上述提到的基本是基于 B/S 架构下的情况。

@bleepbloop #43 漏了说，好像是阿里那传出来的建议...
除了上面说的，还有维护性移植性不好。
所以不建议使用。

@2379920898 #27
原生写 SQL 就被注入，这明显是技术问题，为何因此而觉得 LOW 呢？自己技术学不好反怪原生 LOW ？搞不懂这种想法...
另外你说到 PHP，原生的 PDO 加绑定不是一件很简单的事情吗？连 PDO 都没接触过的话就当我没说吧
最后框架有问题或和业务有冲突，解决或调试的途径不是应该查框架源码进行处理吗？能不改框架尽量不改框架，但前提是你要能看懂框架吧？
没人抵制框架，但框架反而抵制原生.....这真的想不明白....................

@bleepbloop
因为存储过程是直接消耗数据库所在机器的性能，当项目足够膨大，业务性能不足可以拆解服务分布处理，而数据库的存储函数是只能堆硬件。如果涉及执行时间过久的，整个 DB 都拉跨了，但是业务上处理可以进行熔断。