说实话我也觉得很累...
也很怀念以前 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

专线 VPN 正解，其余别折腾了；
所谓的中转，udp over tcp 这些都是为了防止被 GFW 封了；
UDP 常用的话也会被封端口，只能一直换着端口用。

想无后顾之忧，可以办理专线 VPN ，云服务商有提供，但涉境外业务需要报备。

以前异地联网，考虑的是技术上的事情；
现在异地联网，首要考虑就是 GFW 的事情。

@ysc3839 #22 简单的可以，涉及原生插件混合开发的没办法这样做

該說的上面都說了，
num 只要前面有做判斷一般都沒問題，（如傳入負數）。

漏了一個，
3 、函數返回 int 類型時，有些失敗會返回 null ，而我喜歡 throw

1 、偷懶的情況下，如表單驗證，直接 throw 個錯誤，catch 後返回統一的錯誤格式；
2 、事務下，try.....submit;catch..rollback

息事宁人的做法，按它说的改；
暴脾气的做法：
直接回怼并说明详细原因，
建议去（腾讯、阿里、百度） 登录会员页面，替换 token/cookie 尝试，
然后去他们家对应的漏洞平台提交，
把大厂回复你的内容黏贴去报告中，
再反问利用 sessionID 的话，如果复制对应的 cookie 信息，不也是会产生“被盗”吗？

PHP4+MYSQL4.1 升级 PHP8 = 花式作死，跨越太多大版本了
>安全漏洞神马的，不暴露在互联网上面，或者从环境方便直接做好安全策略
这个却未必；
往往渗入并不是靠某一个漏洞来达成的，我朋友在呼叫中心做运维，他们是设定了堡垒机，堡垒机是靠证书登录的，但也被人渗入了，溯源发现是客户端（他们客户的那边服务器被渗入），找到了链接他们机房的 vpn ，进入了业务所在服务器，再通过扫内网发现了其他的 asterisk 服务，然后利用旧版本 asterisk 漏洞进行入侵。

至于 PHP8 ，我觉得有点激进，我平时用 workman ，更换 php8 后除非使用 select 模型，否则 event 扩展在 php8 里有 BUG ，beta 版本的 event 已经修复这个问题了，但其余的扩展会不会有 bug 还不清楚。所以我还是在 7.4 观望下好了。

你应该贴出完整的 PHPINFO ，敏感部分打码，而不是让我们去猜......

雅黑获取 CPU 信息是通过 file("/proc/cpuinfo")的，你可以自己写个片段试试看结果。

@anguiao #5 你是对的，刚查了

JetBrains 于 2015 年 11 月 2 日开始为一系列的产品采用基于订阅的许可模式。这一新模式让我们的客户可以按月和按年购买一个或多个产品。

续费您的订阅并使其保持有效状态，您就可以一直安装和使用最新发布的产品版本。 请注意，我们为基于订阅的许可模式提供永久回退许可证，这是与一般订阅模式不同的。

在连续订阅达 365 天以上（购买年费订阅或是连续续费 12 个月的月费订阅）就有资格获得永久回退许可证。 如果您决定停止续费订阅，永久回退许可证可以让您继续使用对应的产品版本，无需额外付费。 永久回退许可证对应的产品版本是订阅到期日往回推算一年前，当时的正式版本。

L1/L2/L3 是透传母鸡的 CPU 信息，不是专门给你用，别想多了。
就好像支持睿频的 CVM ，对于租户是无感知的，跑分的时候频率也只是显示基础频率

一样，感觉轻量是动态分配资源的；
比方你购买的是 2 核，只是代表你能使用到 2 核的性能，而不是固定分配 2 核的性能给你。
而 CVM 则是分配 2 核的性能给你。

是的
打个比方你是买了 1 年授权，
2022/11/15 ~2023/11/16 ，只要有新版本你都可以升级使用；
2021/11/16 之后，授权过期了你还可以继续使用当前版本，但是无法升级新版本。