比较请先找准比较对象。spaceX 要跟 NASA 比较，特斯拉要跟比亚迪比较，X 就算了，你现在根本找不出来第二个能这么糟践已有成果的公司。你现在回头再看看，spaceX 的成果伟大吗？ spaceX 会比 NASA 更招员工喜欢吗？

建议老老实实烧水用暖水瓶储着用热水。这玩意安全性要求高，耗电量也高。

分公司向上上报信息，或者分公司之间交流信息，有两个主要的难点：一，不愿意送出去；二，最主要的，不是本职工作，狗才加班或者放弃摸鱼事件给你搞。解决完上面两个，才能接下来想技术上怎么处理。如果直接上来就没权的技术人员来解决这问题，陆奇就是前车之鉴。

上云之后，分公司照样各用个的。你强制把文档放到一起，他们会各自创建各自的文件夹。你强制把数据库弄成一个，它们的技术会各自创建自己的表前缀。你强制把主要的数据表都弄成一个，他们的技术会跑路或者继续各自创建自己的主键前缀。

信息孤岛这是管理问题，不是技术问题。如果你的岗位不是副经理、CIO 、或者 CIO 下面一脉的，而是 CTO 或者 CTO 下面一脉的，那么当面试的时候着重问出这样的问题，那这岗位就是个大坑，没过才是值得庆幸的。

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

当然这个管家，是微软中国的（ 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 直接访问。