尝试用 windows 的逻辑去理解 macos ，那本来就是错的
等你用一段时间，理解了 macos 的逻辑，你就会发现：macos 的逻辑确实就是烂啦

答案是，不能。再怎么做也只是增加成本罢了，完全防住很难，收益太低
不说普通的发送 http 请求了，如果用 Puppeteer 和 playwright 这种模拟用户操作浏览器的爬虫能怎么防呢

当年 AM 刚出的时候试用了下，然后再没打开过，因为真的就是垃圾

把你的有用的函数放到其它.py 文件里，然后 import 进来

好像正好符合我的需求？
一直想做一个 mac 一键配置的 shell 脚本（一方面是为了出极端故障时快速恢复，一方面是记录自己做过的配置），所以想要一个干净的 macos 环境试验场，今天就看到这个了
有大佬试过吗？

适应不了就换，大不了自费。
我是 windows 换到 macos 的，我确实同意 mac os 更适合开发。但我认为 windows 的逻辑没什么问题，只是不像“linux/unix”而已。毕竟本来就是两个派系，不能拿一个的逻辑去理解另一个。记得当初大学有一堂课是用 mac mini 做 swift 开发，许多同学就非常抓狂。
而如果要比较逻辑本身的好坏的话，对比一下，我觉得 mac 的逻辑才恶心，分屏、不能右键新建文件、随意的图标摆放位置、文件夹下的.DS_Store 、滚轮和触摸板方向等等。唯一的优点就是好看。
mac 对我来说是 windows 与 linux 的一种权衡的结果，如果 macos 和 windows 让我二选一，那我肯定选 windows ，幸好电脑不是老婆，只能选一个。

虽然不喜欢腾讯，但国内 QQ 音乐确实是最强的了，不建议换其他的

懂你。
刷固件、重装系统的时候一步没有对上自己的期望就想重刷
（中度强迫症）

15 刀，还行，挺值当的
但是看起来 1.0 好像没有关于图片方面的修复啊
我这边如果插入手机拍摄的高清图片或 gif 就会变得奇卡无比。
如果收费的话希望至少能解决掉这种基本问题，毕竟评价标准不同了

一直很好奇，什么样的应用有价值到需要加密混淆呢？

sorry ，没看到已经调用了。
对于 js 这种带垃圾回收的，应该不管它就好了吧？
一般就算有触发垃圾回收的函数，也不过就是“建议”回收吧

好像是 URL.revokeObjectURL(this.src); ???

原来“切换桌面仍然是原桌面”这点都一样啊
我用 pap.er 的时候还以为是我设置问题
看来还是不在 mac 上用壁纸软件了

@KirbySD 不会啊，实际测试：
https://dcsuibian-public-resources.oss-cn-hangzhou.aliyuncs.com/img/Xnip2021-11-19_10-08-56.jpg
调用栈可以看出来的

如果是我的话，异常只在最顶层处理，中间不做 try...catch...

@lesismal 有什么关系吗？说到底，只要能传递信息，你用 get 、post 、还是 put 都是能做增删改查的。
get 不安全还能理解，因为信息直接显示在 URL 里面，可能会被浏览器书签等功能保存下来被别人看到什么的，至少是有理由的。
而 post 和 put 的内容都是放在请求体里，你倒是告诉我请求头里一个单词变了下，为什么就是不安全的了？

@lesismal 了解 RESTFUL 的人都知道吧

@lesismal
既然你了解 http 就好说了。
1. 有人说 PUT 、DELETE 方法是不安全的，我第一个问题就是“为什么 post 是安全的，而 put 就不安全呢？（毕竟 http 的内容基本上是一样的）”
2. 你给出的文章根本就没有回答这个问题，只是说对于 nginx 来说 put 和 delete 是不安全的，不让用。我第二个问题就是“为什么对于 nginx 来说 put 和 delete 是不安全的呢？（毕竟 http 的内容基本上是一样的）”
3. 你所转载的文章说到“开启后，恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。”。但这时候我又有问题了：“PUT 能把病毒文件发上去，为什么 POST 就不会呢？（毕竟 http 的内容基本上是一样的）”
所以这篇文章根本就没有回答“为什么 put 是不安全的？”这个问题啊。
而且根据# 47 等楼的回答，“对于 nginx 来说 put 和 delete 是不安全的”这个观点根本就是站不住脚的，至少不是 nginx 的问题而是运维人员的问题啊。
找到问题才能对症下药啊！！！


文章中唯一有价值的就是“不同部门 /工种在整个工程实践的不同层上的安全考量角度”这点。
如果运维那边说用的软件有问题又不能升级，我觉得后端可以配合一下改。
如果客户说防火墙老旧有问题，后端也可以配合一下改。
如果运维自己水平不行配不来，还直接来句“PUT 和 DELETE 不安全”直接让后端改，这 tm 就是纯甩锅。

为整体考虑可以，但拒绝背锅

@lesismal 这篇明显是有问题的，网上转过来也得自己思考下。
如果实实在在地打印过 http 请求中的内容，看过 http 的格式就知道 method 的最大区别就是第一行的格式。
（ http 是基于 tcp 的，只要你把 http 请求收到的 tcp 内容打出来看看就知道了）

什么叫“从 Java 代码的角度考虑问题”？这跟什么语言都根本没关系，是 http 协议的内容。
“在研发的代码里，终端（浏览器或客户端）过来的流量，最终通过 java 的注解，携带参数进入到了研发写了一个方法里来了。”写这篇文章的人，明显就是直接上手 spring boot ，连基本的 http 协议都没了解过。

至于什么 nginx 会遇到问题，那就去配啊。