好像是 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 会遇到问题，那就去配啊。

退坑的时候还是 1.10 ，居然都过了这么久了

是伪需求。
（我没用过，所以最有发言权）

@bluehr 淘宝买的，不太懂，这个都带照片了还有可能是黑卡吗？

一个略会前端的后端路过。
没接触过 php ，但最开始用 jsp 、jQuery 开发过，也接触过 thymeleaf 、jinja 等模板引擎。

在我看来，所谓“前端工程化”就是用户对 UI 美观要求越来越高，前端工作量越来越大，所以要写前端像对待一个正经工程一样规范化。

为什么模板引擎不适合前端工程化呢?
我的看法：
1 。模板引擎太多了，而且和语言生态圈绑的比较死。
Java 、.net 、Python 生态圈里都有各种模板引擎。
这种时候。这时候，如果你基于一种模板引擎做了组件，那么在另一种模板引擎里就用不了。
这样的话，就算你能封装成组件，恐怕也只是这个项目或公司内部的复用，无法形成 ant design 那样的正经组件库。
2 、模板引擎不适合协作开发。
试想一下，如果使用模板引擎，那么前端开发人员也不可避免地对模板语法有一定的了解。而且还得有跟后端一样的开发环境。
当初我用 jsp 开发的时候，为了看到效果，重启服务器的过程真的是让我心力憔悴。而且更多的是串行开发，后端没做好前台也做不了。
而现在，只要定好相应的接口格式，前后端就可以并行开发。而且前端的代码更改跟后端也没有什么关系。可以专心地干自己的事。
3 、后台的服务端渲染也有问题。
首先，相比于静态内容来说，模板引擎这种东西会更加消耗服务器资源。（不过这个我没数据，所以无法证明影响多大）
这就是后台服务端数据不太完美的地方，对于流量很大的网站比如各种门户网站，后台也得提前把网页模板渲染成 html 缓存。
从响应速度上看不到差别，但网上确实有相应的实例。
4 、JSON 和 html
谁说后端提供的数据只能给前端页面使用呢？
比如 github 的开放 api ，如果返回 html ，那第三方程序怎么用呢？
而且，就算你真的只是拿来做页面。那么如果同时得支持移动端和桌面端页面呢？
。。。


其实还有好多我想说的，但我想直接反过来说，用了模板引擎，相比目前的前端开发模式，有什么好处吗？
可以说直接拉低了前端的上限。

DNS

@yinghuansouqi
尝试过，但好像不太顺利。
我是 shield 。
一开始用的路由器 ，很顺畅。但不想老是开着那玩意儿。
所以也尝试过设置系统 proxy ，用着不太顺。（记不清遇到啥问题了）
最后就是直接装了 clash ，然后把里面一个“dns”的设置关掉（要不然 奈非 会有问题）就可以了。
现在应用基本可以正常使用，但 google 常常说我的 wifi 连不上网（实际可以），手机上的遥控器会经常断开。

好像不会，不确定，我是直接装了个 clash 在盒子上的

不建议这么干，试过两次，都是从夏天开始用冷水洗，洗到冬天。
冬天的时候洗会头痛，别这么干