大家都在或多或少的流氓化，微软再不搞就要被排挤了。

当然这个管家，是微软中国的（ https://www.shitoc.com/news/144.html ），是另外的情况，再不搞点事，微软中国这个销售部门就该上裁员名单了。

单个跟多个的总带宽一样，这不正好说明跑满了吗。这是你的无线总带宽就是 800 ，路由器，或者频道设置有问题。

「不同文件夹的照片不会混在一起」，你先 iPhone 相册能否安文件夹查看吧，我刚翻了一下我的陈年 iOS 12 ，无此功能。

事实上，不建议将手机作为相册的主管理工具，包括 Android 手机，容易丢不说，每次换手机都是烦心事。

merge branch xx into xx 正好跟外部文档上的 merge request 一一对应，是一条非常有用的提交。安心留着吧。

如果你不想让出现 merge branch feature_x into deveop 的提交，那么你需要调整的是修改 merege request 的执行合并的方式，让起实质上只能是压缩提交，或者快速合并。但之前已经做过的，是不能改的。

压缩提交方式，会将待合并分支的所有提交先压缩成一个提交，一般不建议这么做，严重丢失历史。

快速合并有前提的，两个分支开叉的地方，必须是主分支的 Head ，即实际上主分支原地没动，只有待合并分支生成了新内容。要么你需要外部限定一次只能有一个开发分支（这就不存在分布式开发了，实际上连 SVN 都不算，直接回到了 VSS 时代的先锁定后修改方式）。要么得借助于然 rebase ，待合并分支先变基，然后再往主分支合并（这就类似于 SVN 方式了）。并且，你还得配置 merege request 的执行方式是 --ff-only 。

merge branch xx into xx 是一条正式 Git 提交，你要是去了，你会被打死，谨记。

EOFException 是异常到达流尾部，这不一定是连接被断开了，你可能更需要关注 IO 流的生命周期，或者缓冲区的配置。

至于心跳，它更应该当作被断开的感知器，不应该作为连接维持的保证器。

这锅，应该由 Google 不再明显区分广告和搜索结果（背景色区分没了，现在唯一的区分就是广告比搜索结果多了“赞助推广”几个粗体字）来背。

如果不能轻易找到，那就别找了，不用 chrome 才是正解。chrome 的特性就是零配置——你爹都给你配好了你老实用。

这种所谓的文件检测，十年前还确实是防恶意软件的，但现在主要是防盗版的，既然给你上了，那是不太愿意让你自己关闭的。

退换货策略，是买家先跟销售商做，销售商再跟厂家做。同一个厂家，在不同的销售商那里，体验到的退换货，是截然不同的。别说不同电商，就是同一个地区不同的直营店，碰到的服务都不一样。

楼上那个人，就别大放厥词了。

一分钱一分货。

虽然 PUT 、POST 的传参方式，看个人喜好，但是额外遵守一个规范，对个人和团队都有好处。

一般来说：ID 这种明显的目录性质的参数，应通过 URL 本体携带（？ 前面的部分），动态查询条件应通过 queryParam （？后面的部分）携带，而数据则应通过请求体携带。POST 是推送新数据，新数据是没有 ID 的，故所有内容都通过参数体携带。PUT 是修改数据，这需要首先指定 ID 然后指定要修改的数据，所以他需要同时有 URL 参数和请求提参数。

当然，如果 PUT 请求的 ？后面还带了业务参数，那不影响功能，但是个大坑。

@PostMapping 只能接受 http method = POST 的请求， @PutMapping 只能接受 http method = PUT 的请求。单独 @PostMapping 的请求，如果你拿 PUP 去请求，回收到 405 Method Not Allowed 。反之亦然。

@PostMapping 跟 @PutMapping 就上面那点区别。这是强制性的编码逻辑，不是非强制性的规范。虽然楼上几个确实在回复楼主真正该问的，但是对于原始问题的回答，是错的。

楼主真正该问的，是 http method 中，POST 和 PUT 的区别。这俩在「 URL]和[参数载体」上，是一模一样的，没有区别。POST 、PUT 的参数，都是可以即用 URL ，也可以用请求体的，具体怎么用看个人喜好。它们的区别，主要在接口本身的用途上，简单的说：POST 是推送新数据，PUT 是修改现有数据。

一天一个来回 60 里地，骑车，想想都刺激。

请注意：常规的自动负载均衡策略下，要求多个节点完全一样，包括后期上传的文件。「上传文件时就可能会上传到任意一台服务器」，这个行为本身就是一个 BUG 。

方案上面已经给了：用其他同步措施，把多个节点的后期上传文件，做同步。这个虽然是最简单的，同时也是绝大多数情况下最合理的。

当然如果你要更合理的话，那也有稍微复杂点的方案：
首先，将上传和下载路径的前段部分（含绝对路径），都做成可配置的（而不是自动获取当前服务所在目录）；
然后，不管是哪个节点，上传文件都保存到一个位置，这个位置与后端服务节点不绑定，而是与宿主服务器的文件系统和 Nginx 绑定；
最后，给 Nginx 配个映射，让上传文件能通过 Nginx 直接访问。

一两百的双肩包，不会有耐用的，没必要推荐。推荐还是随便弄个不那么难看的单肩包应急，平常就别背东西上下班了，被东西上下班这种东西，最多半年，一般一个月机会腻的。

如果不是上下班，而是职能出行，建议不要扣，再加两百买「威戈」。

淘宝要把消费挤到 11 月 11 号那一天充数字的，要是预热太早会凉。

信用卡是借贷不是储蓄，它没有余额只有账单。消费是账单正项目，还款是账单负项目。最后还款日是最后清账日。至于最后清帐日之前，消费和还款的顺序是无所谓的，所以你在消费之前往里面充钱，对于账单来说就是还款。

如果还款多了，造成最后还款日，账单结果不是零而是个负数，这虽然没平帐，但是不影响清帐。这对银行没任何影响，对于用户来说也没丢钱（只是被套了），所以基本无需处理。

@iOCZ #18 那是明面上的，实际上是卖了海外资产把国内银行债务提前偿还（把学李嘉诚跑路的念头给掐死了），顺便清理了一些国内的低资产，你看万达电影这种一本万利的，跟万达影院这种被特别灾难快冲死的行业，妥妥的大文娱，它是一点都没卖。