忘记说了，没有 CI 平台也是可以的，但这时开发要交付的不是代码，而是 Docker 镜像。

开发环境的需求是统一开发运行环境，生产环境的需求是统一交付。

对于开发来说，重点是“运行环境”，对于生产来说，在环境的基础上还需要加上开发交付的代码。不管是虚拟机还是 Docker，都可以提供一个统一的运行环境。

环境的统一可以使用约定基础镜像来实现（ FROM IMAGE ），实际开发中需不需要使用 Docker 容器远程 Debug，取决与实际需求，个人是觉得再提交代码之前开发本地用 Docker 运行测试代码即可（ VOLUME ），倒是没必要追求必须在容器中完成开发过程。

开发交付时还是交付代码，利用 CI 平台进行 Docker 镜像构建（代码包含在镜像中），部署到生产环境时则是部署镜像，根据实际情况可能还需要对配置进行管理，之前参加的交流会看，有使用环境变量传入容器的，也有挂载配置文件的，也有不同环境不同镜像的。

另外也不觉得只要上 Docker 就得直接上 K8S，根据业务规模和需求 Docker Swarm 也可以考虑的，甚至仅仅单机靠编排文件（ Docker Compose ）也是可行的。当然，本着面向工资的原则尽量还是上 K8S。

对于开发来讲，Docker 实践中需要注意的一个是日志处理，另一个就是环境配置了，日志已经有人说了，补充一下的是 Docker 的日志还是有挺多诟病的地方，根据解决方案不同，代码上也可能需要做一些处理。Docker 官方的推荐实践是通过 stdout 和 stderr 输出，然后使用 logdriver 配置容器日志输出和格式。环境配置官方推荐的方式是使用环境变量作为配置，这需要在代码中获取环境变量，当然，实际怎么做是不断妥协的结果，并不是一定要如此。

不签合同无非就是开你的时候省事，既然获得了收益就要付出相等的风险，当然你也可以轻松的离开，Business is business。

@zscself 这块我看错了，我道歉，不过还是认为这事完全没必要专门发个贴找认同，98 楼已经有说。

Python 有些坑，一部分原因是 win32 库，一部分原因是 Windows 平台编译 C/C++ 依赖问题。

基本上跨平台的编码，换行符问题都会被工具自动解决掉，需要额外注意只有文件系统限制不同造成的差异，大小写敏感度、文件名或路径特殊字符。

又仔细看了下，是我理解错楼主的意思了，应该是新来的毕业生对楼主同批的其他同事都叫哥、姐的，唯独对他态度有差异。不过，依然不觉得这能算多大事，值得专门发一帖。

仔细看了下，同龄新同事刚好晚 4 年进公司，估计楼主学历比较渣。大概新人工资待遇什么的持平甚至更高一点，只能说心里有危机意识但是不想承认吧，说到底还是一种自卑心理的过激反应。

同龄，就只是个 team leader 而已，该怎么叫才叫尊重？ x 总？

@incompatible 当然是 golang 了，毕竟现在没个百万并发的项目都不好意思在 v2 发帖。233

@mt7620 不如直接买个最低端的 100M 三层交换机端口限速。:doge:

淘宝买 J1800/J1900 4 Intel 网卡整机，注意：必须要 Intel 网卡。

如果终端数量小于 250 个，推荐国产免费非开源 panabit 标准版；如果大于 250 个，无责任推荐个爱快（免费不开源），不在意七层 DPI 功能可以选 OPNSense （开源，有中文）。

直接用代理就能避开单纯 IP 限制，而且单纯通过 IP 限制以目前国内 ISP 大量分配内网 IP 的情况看，很容易误伤。

反倒是服务端这边如果有做反代，需要添加额外的 header 来让后端获取正确的 ip。

如果 nas 上端口应该是 443，外网映射成 4443，1.2.4.8 代表外网 IP，那么就应该是因为路由器（网关）有回流造成的。

@okzpy9425

都到应用层了在去说传输层不是扯么，要较真的话去读 RFC 最直接。

举个例子，在 RFC 中并没有限制 URL 的长度，仅仅是说 “ It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.” 也就是说上所说的 GET 请求因为 URL 长度有限制，这个并非协议所决定的，而是各个客户端（浏览器）和服务端的实现决定的。至于其他的“可以保存为书签”、“会有历史记录”，“浏览器会默认请求 GET ”，这些都是客户端或服务端的实现而非协议的规定。

HTTP 协议描述中除开明确说明 “ MUST ” 的部分，其他并不是强制性的。因为 HTTP 协议并非是先定好协议规范，然后大家再来根据协议实现，很多时候各个厂家实现的功能并不会在当前的 HTTP 协议上有描述，协议制定组织也会根据实践来修改协议。换句话说，对于 GET 请求的中规定，只要没有说明“ MUST NOT ”在 POST 请求中如何处理，就算在 POST 请求中实现了，也是符合 HTTP 协议的。

@qinxi
RFC 中对 POST 的描述是在一定条件下也是可缓存的。

get 也可以带 body，只要 client 支持，server 处理。同理，post 也可以有 query string。

get 幂等与否要看 server 端如何处理，说到底各种差异是 client 和 server 如何处理造成的，协议本身来讲就只有语义差异，但本质上没区别。

https://www.bilibili.com/video/av12656134/

其实这玩意没那么美好。