@coloz
《个人健康信息码》系列国家标准包括《个人健康信息码 参考模型》（ GB/T 38961-2020 ）、《个人健康信息码 数据格式》（ GB/T 38962-2020 ）和《个人健康信息码 应用接口》（ GB/T 38963-2020 ） 3 项内容，由国务院办公厅电子政务办公室会同卫生健康委及国务院相关部门研究提出，全国信息技术标准化技术委员会负责技术归口。

!( https://i.loli.net/2021/01/04/evHKFBomCbnYfpE.png)

这个应该是你要找的接口，但是没有公开申请途径，暂时是由卫监局负责。
反正就是没说允许公众申请，还是不允许公众申请吧....


这个接口需要申请才能使用。

鸟哥的博客一直有谈 PHP8 啊...........

没用的，的确是可以区分，但是抖音太多人科普这些了，现在查岗的基本都带这项技能了。
还是两台手机实际点，第二台最好是功能机

@WishMeLz 又 app 又 H5，猜测你们是用 uniapp 吧？如果是 uniapp，我试过几次生成 app，安卓打开图片不显示的问题，重启又好了，偶发性的。另外其实看业务性能，即使上海外 CDN 未必就能解决，毕竟 CDN 是需要回源的。

@WishMeLz
对了，我之前得公司，老板几乎是这样的，不区分节假日，24 小时他发现任何问题都会喊。
不过非休息时间（节假日）的话，他会打电话让你帮忙看下。--带着请求的口吻。
休息时间（深夜凌晨），他会等次日再电联处理。

@WishMeLz
enmm...
该怎么说呢.....
未经他人苦,莫劝他人善。

针对这件事，不好评论什么。
但是不负责任的话高低还是能来两句，
在老板角度，他认为我支付了这笔钱，你们就应该提供到我需要的服务，而服务出现问题了，别说是什么日子，因为在他角度就是 1+1=2，但是得出了 3，所以他会认为是员工能力问题。并且觉得自己可以不追究员工算错数，但是必须解决，最起码要吭声。
在员工角度，你给的这笔钱只是包含了我工作时间处理问题，节假日的时候别烦我。出错了是因为没测试，是程序就会有 bug 。

大家角度不一样罢了....
如果是大公司，那么节假日安排人员轮班避免这种情况；
如果不是大公司，只能说大家多点包容；

反正都不容易，能体谅多一点体谅，能包容多一点包容，自己实在觉得憋屈的就走就是了，没什么好说的。

@vicence 不通......
幫你组织下语言吧，
用户请求处于服务器 A 的一个网页，
可是网页中包含服务器 B 的资源，
而服务器 B 和用户所在的网络事隔离开的，
请问用户能正常加载服务器 B 的资源吗？

1 、节假日期间，用户量大的话肯定安排 1~2 个留守值班，人不够的情况下各退一步远程值班。值班并非为了处理问题，而是记录问题，及时反馈。
2 、如果公司没这项安排，恰好我自己又是该项目负责人的话；看到了，不回复，我职业道德问题。没看到，迟回复，别进行道德绑架。

看了 LS 的回复，我没看过 LZ 之前得帖，不清楚前因后果，但反正什么原因，我觉得开发最重要的还是责任心。互换角度，其实都不容易，2020 考验的是中小企业老板抗压能力。

其实拖报销稳资金流的看法我不同意，
一个公司的资金流不可能因为被报销给左右吧？
除非全都是垫资货款....但如果需要垫资货款，那问题就不是报销慢了吧....

我们这报销流程比较简单，
发票 /收据，发申请，部门主管同意就到经理审批。
经理审批后会实时垫资给员工
整个流程 3 天内完成。

但财务那边计算 1~2 个月才会拨款下来个经理....

挂代理扫漏洞的...
同 IP 访问频繁的直接 ban 了就好了...
我上次就是这样不小心 ban 了个 CDN 节点....
后来..............

webp 到现在都没推广开来，
TPG 提供商业服务，但是针对 web 场景也无能为力。
HEIF.......

這個和 mysqli_query 沒多大關係吧...
mysql 欄位正常寫法就是``,
sqlserver[];

然後插入的字符 ''。

@binux

你知道 X-HTTP-Method-Override 这样的方案吗？<---確實之前不知道。
但剛看了，需要後端配合，當收到 X-HTTP-Method-Override 時候重寫 method。
但其實就是過了安防那一塊吧，waf 等不需要進行處理，nginx 等也不需要額外配置其他。
還有就是後端一開始如果是完完全全按 resetfull 設置的話也可以不用進行修改。

但是如果我援用 POST 來跑，除了優雅，性能上有多大的區別呢？

如果是新開發的應用，用什麼大家提前說好了我覺得問題不大。
但是修改現有系統，你覺得呢？除非我是老闆，否則我單以“優雅”二字要求後端和前端去修改，可能性不大吧。


“从小的地方，这里改一点，哪里推进一下。当真的要推一个重新设计的时候，你会发现这时就不这么难了。”
這句話，我以前一直都相信。
但是往往是，“这里改一点，哪里推进一下”，最後出 BUG 了，然後修復後整條業務線平靜下來，我得到的只是罵名。
（*說句題外話，曾經試過，幫別人修改一下 HTML 靜態文件，然後過了兩天，對方 oracle 掛了，對方運維排障，前 2 天有人改過東西。嗯沒錯，這鍋最後我背了，後面排查是因為 listen log 超 2G 的原因，但也不重要了，反正鍋已經牢牢扣我身上）

@binux 哈哈，又見面了，上次我記得也是在說 api 規範上面討論過。
首先我認同你所說的，我年輕時候也是這樣想，為什麼沒有人能打破陳舊？
但每次打破陳舊的背後背負的責任實在太重了，現在年近 30，雖然沒達到你說的 35，但我的思想已經接近了，以前留下來，沒有大問題，不做修改。

回到題主的問題中。
我不可能頂著壓力，跑去懟全世界，要求把 api 接口都按 resetFull 重新設計，然後說出一大堆冠冕堂皇的理由，但最終明眼人都能看出來，這小子為了“好看”，“跟風”所以要求改。
老實說，使用 PUT/PATH/DEL 來處理對應的業務，除了優雅外優點在哪裡？


對了，不是不願意學些，而是不願意在生產環境上學習。
我記得你說過你的業務基本是對接海外的產品，那麼我只能說國內環境不一樣。
就權當我能把運維前後端說服了，
大家都願意去對現有系統進行修改。
然後後端出現了一個新的問題。
此時此刻，後端心理肯定在罵我的，甚至還想甩鍋給我。
國內的環境你有時間可以看看阿里雲的前世。