我看 next.js 教程的时候发现 有几个 meta 标签，og:title, og:image 这些。

https://nextjs.org/learn/seo/rendering-and-ranking/metadata
https://ogp.me/

他们应该是为了适配 Facebook 和 twitter ，以及 PWA 卡片，不知道国内支持度如何。

@Bingchunmoli
基本上其实都差不多，常用的 isEmpty ，isBlank 就两三行，自己手写也和那几个工具类差不多，
除此之外还有一些方法就是 String 默认方法包了一层空判断，比如 trim ，startWidth 之类的。

我说这个只是类比，剩下的加解密、json 转换、日期转换也是好几个库都有，但选择的时候我还是优先选择了那些知名的、用的人多的。

@GTim 但这些年我才突然发现，有些人真的是不能接受他认为好的东西被别人说一点不好，哪怕是事实...



我其实还是用 hutool 的... 只是相同功能的 util 我会优先用 spring 和 apache common 的

@runzekk 那是，还是您配，毕竟您是学会了释放冷气才去评论冰箱的。

加油，争取有朝一日您有能力把我们这些阻碍社区发展的阻力都物理消灭了。

@runzekk

“你不去给开源软件贡献，还在这无端指责，说你是开源软件的阻力，有错么？”
哇，那你们不应该做开源啊，你们应该去找人抱团做饭圈啊。

我说 spring 太臃肿的时候，我也拿不出证据了，毕竟我太主观了是吧， 我原来是开源的阻力了。
我说 apache commons 的 Bean copy 性能太差，还没给他们贡献过代码，那我是不是就应该是 Java 社区的罪人了。

另外建议你们别用现有的开源协议，你们得自己写一个 license 把你们的诉求也写进去，毕竟这些协议 “居然没有禁止别人在不提交代码的情况下评头论足，开源协议里就应该把这些阻碍社区发展的白嫖怪轰出去”

@jdOY 如果你简单了解过相关工具的对比文章就会知道，apache commons 的 BeanCopy 效率差是大家都知道的事实，说这个事实就是为了告诫其他人在新项目里少用，而不是为了逼社区改。

人家不改是有充分的理由，就是为了兼容，为保证之前的使用者不会在更新后就出现不一致的行为。
你提 issue 也只会被人家指向最初那个不予修复的回答。


最后，使用和谈论本身就是一种促进社区活跃的行为。

如果你们的思想是 “用你们开源就是欠你们的，就是白嫖，就没资格评价这个开源东西好坏”，那建议你们别开源。

linus “fuck nvidia” 的时候也没给他们提 issue 更没有给他们写代码推 pr 。

@adoal
其实是有关的，热衷于 hutool ，ruoyi ，mysql-plus 的大多数真的只是糊裱匠，“我只管最快速的干出来, 不出 bug 不就可以，工作而已何必较真”

就像做饭，有些人也推荐预制菜，买个半成品回家，这边一热那边撕开调料包倒进了不就好了，像方便面一样，犯得自己搞么，择菜洗菜自己弄半天还不如人家调料包香。

你说预制菜做的不好吗，其实 有一些真做的不错的，而且对于水平差的人，预制菜真的做出来的水平真的比它自己重头做好非常多。
但我不喜欢预制菜的统一口味调味料, 我觉得煎炸炒用同样的料包做出了的味道虽然也都好吃，但比不上我煎的时候配煎的料，炒的时候配炒的料做出来的香。

@smilenceX
我其实是城里人，但 2000 前城里也是平房多啊，所以前面的我都经历过。

至于后面那个则是去大姑家和回姥姥家的记忆，他们也是每户自己盖厕所，毕竟当时大家还都自己沤肥，但他们的旱厕我记得好像那个坑上盖的是一个废弃的门板吧... 反正走上去那木头板子上下颤动，我是非常害怕它塌了，毕竟掉粪坑淹死这种死法太有震慑力了。

@runzekk 凭什么不能说，好与不好不是有客观事实评价标准的吗？

我说 apache commons 不好的时候我也得加入才行？ 我说 apache BeanUtils 的 copy 性能特别差是不是得先给他们提 issue 才行？

@smilenceX 他是说旱厕和现代下水系统的区别。
看你能不能接受夏天味道特别冲并且低头看到的是一片白茫茫蠕动的蛆，
冬天则是地面上尿水溜冰+是真·屎山，坑旁边是垒的砖头，这样才能你踩着砖拉不沾到屁股上。

当然也有可能是安全问题

有些旱厕直接就是一个大坑上搭个木板，站上去心惊胆颤，还有些真的旱厕连着猪圈，你对着坑下面那个长着大口活物非常害怕生怕它顶你一下。

我可以决定的项目里我会禁止引用 hutool 或者只引入核心，因为 uuid 和雪花 id 确实省得自己写了。

不想引入的原因很简单，同样一个 StringUtil ，存在以下选项的时候 spring,commons-lang3, guava ，commons-lang ，hutool 的时候我选择大厂背书或者社区核心维护的库优先于 小众群体维护的库不是很容易理解吗。

写代码连尽量不堆屎山的追求都没有，心态就是混口饭吃，那你不论干哪行都是咸鱼，当然了，当一天和尚撞一天钟的人也许才是大多数。

至于公司项目，不归我做主，我也没必要非当事逼逼着同事改代码，那爱咋样咋样，领导有追求我跟着干，大家都无所谓我也不逆势而为。
所以公司项目引入乱七八糟，上面那几个同功能的库都有，有的甚至会由于依赖导致重复引入了同一个库的不同版本，那就引呗，再加上有些同事自己攒了多年自己写的工具类，以及接入某写 SDK ，人家示例代码里的 util ，五彩缤纷。

40%、50%的失业率，各位可真牛逼说这话的时候都没过过脑子，老美大萧条时候都没这么高，到这数了还没有遍地造反那只有两种可能：
1 、剩下 50%的就业人口全部都是秘密警察，时刻监控这些失业的。
2 、智械时代来到，人类靠剥削机械产出已经可以完全脱离任何工作，还在参与工作研究的都是自己兴趣爱好。

后面有哥们解读说人家原文指的是初入职场的新人的就/失业率，那还有可能，因为现实环境确实很恶劣，但即便 16 年不恶劣的时候有一说一这个青年失业率估计也不低，
我同学朋友里头学文的、学机械、学化工的都大部分找不到满意的工作，最后一大半都转行了，学的和干的完全无关系，而且有时候还会多次转行跳槽，我感觉好像这个才是常态，只有 it 、金融、警察军队等少数几个专业毕业后找专业对口工作的人多一些。

@baiyi 你不回最好，减少了这个世界上的无用信息和戾气。

要不是后面另一个哥们指出了我的错误，我缓和了一下心情给他先点了个赞，我也不可能维持一个好心情给你也施舍一个赞。

@Mac0ne
你提到的几个方法里，OPTIONS HEAD 这些几乎标准后端默认都支持，但你说可以用来 DDOS ，那 GET 不也一样可以，而且效果还更好。

PUT 、DELETE 、TRACE 又都不是标准 http 服务会默认提供标准行为模式的方法，甚至老实说 TRACE 我都实际当中没用过，许多 http 软件都完全不支持这玩意。

不要觉得全世界所有人用这几个方法都是去搞 WebDAV 服务了，觉得这几个会影响安全，那只能说你们运维是真的水。



我们项目有以下几个接口，麻烦你分析一下哪个会产生篡改数据的风险，哪个会产生数据删除的风险，哪个会影响服务器上的磁盘文件：

DELETE /api/users/{id}
PATCH /api/system/info
PUT /api/stations

如果这几个接口有风险， 那请问，以下接口为什么在你的认知里就是安全的，当然如果你认为以下接口也不安全，那麻烦给出整改意见：

POST /api/delUser?id={}
POST /api/system/updateInfo {a:1,b:2}
POST /api/station/addStation {name:'xx',desc:'abc'}

非要保证递增，那就只能使用锁或者单独的 id 生成服务，以并发的代价来保证 id 生成同一时间唯一。

@baiyi 你说的对，还是你理解深入，给你点赞

@baiyi 这东西不是百度谷歌随便一搜就找得到么

https://www.ruanyifeng.com/blog/2011/09/restful.html

https://datatracker.ietf.org/doc/html/rfc4918


restful 作者只是提了一个想法，但没有形成什么明确的规则协议，所以关于 restful 的细节大家各有各的理解，因为最初的作者就是论文里笼统一说，不像 graohQL 。

而 WebDAV ，这玩意出现的不算太晚，但最初人家都是自己客户端和服务通信的，只是基于 http 协议了而已，这样不安客户端的用户也能查看，它和 gRPC 一样，属于特定领域在 http 上实现的私有协议。
WEB 主流世界用不上他们这功能自然支持情况很差，尤其是后端，这是 spring 官方有我提到的那个拦截器的原因，因为在 restful 火起来的同时期的 tomca 7 吧还是 8 都还不支持 PUT 请求。

楼主的问题我们也遇到过，但你们的 QA 估计就只会背八股文，知其然不知其所以然，实际上是 WebDAV(对小白)不安全。
restful 是 作者发现人家 WebDAV 搞的这套 http method 很符合他的想法，所以复用(偷)了他们定义的 http method 而已，仅此而已，实际两者没什么关系。



而安测会将这个提示为风险的实际原因是针对小白的规则拦截导致被 AOE ，根本原因是有些小白用 IIS 或者其他一键脚本开启了 WebDAV 服务但没做鉴权，效果就和允许匿名的 FTP 服务一样，导致文件被脚本小子加密或者删除。


我们是某个合作的甲方人家找的安测出的报告里包含 “中风险漏洞: 使用 PUT ，http method”, 不过人家给的报告还包含里处理建议/参考， “打开服务设置，选择 IIS 服务器，关闭 WebDAV 服务”，所以我们一看就明白了

另外我们的要求只是高危漏洞必须处理，其他的可以商量，所以我们就解释说明了一下就 ok 了，如果你们的安测是甲方
的而且道理说不通，要求必须按规定，按他们原有的测试脚本，那你只能投降了。



-------------------------------

最后如果楼主只能改了，那也不算非常麻烦，spring 有个拦截器可以把 POST( "xxx/api", {"_method":"put"}） 转换识别为 put 请求，这样整体后端代码就不用改了。
前端呢也可以将 http 工具再封装一下， 把其他 method 改成 post + _method 参数的方式。