我之前遇过；
1 、偶现现象，但发生了之后后续基本 1~2 分钟内会继续发生。
2 、内存原本是插 2 条 16G 的，后来拔了 1 条后恢复正常。
3 、把另一条插上又会出现之前的情况。
---最终只插 1 条内存。

另外一种现象：
IO 占用 100%，但读写速度只有几 MB ，（ NVME 盘），但重启 10 次，有 2 次会正常。
正常后一直都正常，不正常的话鼠标移动都卡，移动的快音响发出滴滴滴滴。
暂时还没解决，之前猜测是盘的问题，但这个盘之前做 nas 的系统盘没出现过任何问题（稳定运行 1 年多），只是装了 win10 做系统盘后才这样。

1. nohup 配合& ，可以解决后台运行的问题。但是比较简陋。而且没法处理有交互的程序。
不知道为什么到你这成为了简陋...我觉得这个简直是万精油....
另外需要交互的也不会丢后台运行吧......

2-5 ，常驻运行的我一般会上 systemd ，只是配置的时候麻烦，但后续使用方便。
而你提到的其他那些，要启动运行的话可以把运行脚本丢去 init.d 里面

@shuimugan #10 serverless 的坑你慢慢就体验到了

@exploreexe #84 uniapp GooglePay 不携带因为不是刚需，而且也要留一口饭给插件开发者。
你提到的 uniapp 连个 googlePay 支付 /第三方统计 都没有，只适合小程序 实在无法赞同，
敢问 flutter 是天生自带了微信支付和支付宝支付吗？

我不清楚 flutter 的环境，但就 uniapp 而言，原生没带的 sdk ，你可以自己封装下 ios 和 aos 的插件官方 sdk 给 uniapp 调用，如果你不会怎么封装，插件市场 常规的基本都有的购买，冷门的也可以找别人开发，论坛一堆原生 sdk 开发接单的。

Flutter 没用过，UNIAPP 倒是常用，IOS 和小程序都上架了。
上面也看提到了小程序和 APP 的对比，
我自己的看法是 APP 能实现小程序很多无法实现的功能。只是肯能太细你们没看到，另外小程序早就不是 2M 了，有分包加载功能。
1 、图片
对于 APP 而言，我习惯的是把图片资源缓存，后续只需要检查沙盒里面有没这个资源，避免重复加载，这一点在小程序是无法完美实现，只能基于 web 的缓存。

2 、长页面长列表
对于 APP 可以通过对应组件，达到不可视区域的资源释放，但是在小程序中(web)，当列表达到一定程度（特别是包含图片的），直接就卡死了。

3 、支付方式
小程序中除了微信支付还能用什么支付方式？但 APP 可以使用不同的 sdk 不被受限。这一点对于港澳台业务的非常重要。客户人群有使用微信，但却不是使用微信钱包，而是使用当地的第三方支付渠道，小程序中就没法直接拉取支付。

4 、分享
安卓的小程序可以分享朋友圈，app 则不受限制，常规做法都是 app 搭配 H5 进行分享。

5 、小程序常年改接口.........

所谓的超融合其实就是现在云厂推的无服务器应用...单纯跑一个应用的。
只涉及到存储 /计算 /带宽 能力。
和虚拟机完全不是一个级别的。
另外阿里 ecs 也不是一台物理机器；

存储->建立存储池，末端是多台物理机器；
CPU/内存->集群中建立的虚拟机；
比方 A 集群中由 3 台物理机组成，虚拟机的配置运行仅仅会在其中一台节点中生效。
当发现这个节点异常时，集群会把配置文件移动到另一个节点中。由于数据的存储是存储池中的，所以这个移动其实仅仅是配置。

如果你有租用超过 3 年的云主机，你细心查看会发现有过自动重启的日志（可能看运气吧，但我其中一台试过），提交工单后答复由于宿主机异常，导致了转移，所以引起云服务器重启....

内存带宽大概是 4200MT/s ，网络带宽需要达到怎样的条件才能这样异地组机呢，而且还没考虑稳定性...
这有点过渡设计了....

我们那时候是小学有电脑课，几年级开始就忘记了，电脑室都是贴着“学习计算机要从娃娃抓起”的标语

@fangcan #5 发现了的人未必会公开，可以售卖。也可以自行利用。
常规的安全测试针对的是已发生过的问题，不会对未发生过的进行测试或有案例。
review 时候一般遇到古老的库都只是会查下是否有通报，而不会重新进行检查。

一般来说，针对这种漏洞，除非专门找白帽子做人工渗入，但老实说如果我这个漏洞可以卖 10W 美元，或产生 10W 美元以上的利益，我还会为了你那几万块的奖励提交出去吗...

理性的說，
1 、教育机构哄抬；
机构会让你没工作经验的时候，就说自己有 1 年的经验，开发项目由于涉及商业信息无法展示，但是有个人作品（培训时做的）；-----前员工告知的，但他觉得自己都难以置信，所以才坦白。

2 、之前互联网大环境下导致了；
对于培训机构或学习这个专业的，他们一般都有自己的群，里面几十个人不乏比某人差但待遇更好的情况，甚者还有一跳加一倍的情况，所以导致他们关注点永远是薪酬而不会考虑和自身能力挂钩。

3 、职业行规
对于一家公司做 3 年后，薪资基本不会太大调整，想要调整就必定要跳槽；但他们往往忘记了，这句话只适应于你的能力也得到提升，而不是 3 年的 CURD 。

最后，我觉得搞 PHP 的由于台阶比较低，互联网高潮的时代我见过很多之前装修 /工地 /辍学 的人跑去培训班，然后直接跑出来工作。毕竟 PHP 上手简单，所以相对其他语言要学习的知识比较少，基本就语法就行了。不行的就百度上。

据我了解招聘公司开出的：
广东-23 线：3K~6K
广东-1 线：5K~30K

应聘人员期望的：
广东-123 线：8K~30K 或 6K+工龄*1K

PS. 顺便吐槽一下这个 kisshere ，太典型的反映了当代程序员的思维：1. 喜欢伸手就來張嘴就噴.2. 越大越复杂越臃肿功能越喜歡用開源的卻還一毛不拔

说实话我也觉得很累...
也很怀念以前 jQuery 一把梭的时候。
从最早期的原生 js 到用 jquery ，再到现在的 vue ，
诶~不知道怎么说

其实我是这样认为的，通过论坛帖子拿到最终解决方案并且实施成功是不可能的，
这需要你各方面的知识和平时的规范。
NAS 为何卖那么贵(对比自行组装)，那是因为它的软件已经针对常规的安全隐患进行处理，你只需要定期给它更新即可。

经常有人会让你用一大堆开源方案，搭建个 NAS ；而实际情况却是你会遇到很多各种各样的奇葩问题，自己有能力解决的情况下还好，自己没能力解决的时候你会发现你又浪费了一天。

我就是之前用了开源方案后，被各种坑，随后才换了黑裙.....
不过相对而言，哪怕是开源的 NAS ，安全策略配置也比你直接 win 开外网好...

兼容场景比较大的时候，就能体现出 refreshToken 的意义；
比方第三方服务商，简称 A ；
自己的后台，简称 B ；
自己的前端，简称 C ；

疑问 1：
参考 JWT ，token 中可能包含着用户信息，token 有效期过了但 refreshToken 的没过，此时只需要通过 refreshToken 就能更新到用户信息了，对用户无感知。
如果没有 refreshToken ，则需要用户重新登录进行验证，这个时候会产生交互操作。

>然而当 refresh 也过期的时候，依然要重新登陆。
正常情况下通过 refreshToken 刷新，refreshToken 会返回一个新的，过期时间上自然是会延迟了，所以不会存在操作中需要重新登录。

*如果是说把用户 账号密码存起来，过期后再静默进行登录达到刷新 token 的话，那其实账号密码就充当了 refreshToken 角色，但这种做法可能会导致泄露用户账号密码信息，所以需要 refreshToken 。


疑问 2：
当 C 需要调用 A 的服务，会携带 token 发去 B ，由 B 发去 A ；
此时如果 C 发送的 token 超时，B 会通过 refreshToken 去刷新 token 的时长，然后重发请求给 A ，再返回结果给 C ；
这种场景中 refreshToken 并不传给 C ，而是 B 自己保存着。


以上是我自己对于 token 和 refreshToken 的见解，不过如果 token 是我自己产生的话，我会采取单一 token 形式进行，因为我自身业务可以不用考虑上面的场景，但 oauth 的设计考虑到的场景比较多，所以才会这样。

@dafen7 #23 这要求我们之前也提交过工单和腾讯云工程师了解过，他们也表示出无奈，因为某些原因他们无法处理类似这种跨境业务的网络问题，而且他们也明确表示了，如果真有技术方案能解决这种问题（前提是稳定性），那专线将变得毫无意义。我觉得这句话挺合理的。
而且封禁这个并不属于技术问题，而是政策问题。
打个比方就是 如果你们通过 UDP 进行收发，但是服务偶尔挂起，那你遇到的是技术问题；但是当 UDP 收发时，端口偶尔被禁，这属于政策问题；哪怕你当时更换了端口或使用别的方法绕过去，但一段时间后也许 GFW 也会把你的方式给封了。所以回到源头这种政策问题就应该按政策形式去处理，而不是找技术方式进行绕过。除非接受稳定性降低。

@dafen7 #19
我之前有个香港的业务，用的是 IPLC 专线，除了线路维护（提前 1 周会通知）外，5 年来基本没出过任何问题。
听说是 2000HKD/月，从香港那边申请办理的，2M 带宽。

后来有个业务需要也需要涉及港澳，自行在良心云购买了两地的服务器，自建 openVPN ，运行 2~3 个月的就被封端口。流量也不算大。折腾过很多方案，二次封包，加密等的....基本无解，感觉流量识别并不是解密流量后进行封，而是识别长期连接同一个端口触发封禁，当然具体我也不知道，GFW 规则那么神秘。

而且你们的还是数据同步，这种对于稳定性要求比较高的，考慮国情因素，因此建议 IPLC