小鹤用户+1，一直没有动力去学形……

strace 一下看看？

添一个测试环境，配置正式推送到线上环境前先上测试环境跑一遍必要的 HTTP 接口测试。

换个思路吧，服务器 A 上生成文件列表，然后切成几个文件，分发给不同的 IP 去下载（ rsync 可以从文件列表里读下载文件。）

一个是看看上个容器出错的原因，比如 mysql 这种，出错日志会打在 stdout 里； docker ps -a 看看所有容器里刚启动就崩溃的容器，然后 docker logs 看看有没有错误输出。

另外一个方法就是调试，如上面的大佬们说的，用 sleep xxxxx 或者 ping 127.0.0.1 作为启动命令（ 1 号进程），让容器跑起来，然后 docker exec 到容器里手动拉起服务看看报错。

一个样式上的小 Bug: 鼠标放在工具栏最右侧"..."上会显示"更多"，点击 "..."后，"更多"一直悬浮着，会挡住下拉菜单第一行"代码块主题预览"的前面三个字。

试用了，给楼主点赞。

通过 ARP 一层层查交换机上 MAC 地址和端口对应关系最靠谱。

P 个 S：比如 C++ 里 MCP 框架用共享内存做 MQ 这种玩意……

哈哈哈我有类似的体验，但不仅仅是刘海屏，还有渐变色后盖，实在接受不能……

我的理解：K8S 的设计就是为了解决容器生命周期问题。"主进程即容器"这样的概念可以把主进程精确到单个容器的颗粒度来管理。换句话说，如果你想在容器里跑后台进程，那么就需要另外一套机制来确保后台进程的生命周期（比如怎么启动后台进程，怎么确保后台进程存活），用 supervisor 或者 systemd 之类大部分是非云原生系统上云时候的过渡方案（又不想花精力做微服务拆分，又想容器化）。
阿里还专门弄了个富容器的概念，也是盯准了有这类需求的客户。

https://www.v2ex.com/t/454943
https://www.jianshu.com/p/d7dbeffc2dff

从技术的角度，我不喜欢这种做法，非常别扭。但从商业角度来看，是一种很 lazy 又讨巧的上云方案。

最近有孟京辉《恋爱的犀牛》。

在深圳的话我也不知道有啥；外出的话可以给楼主推荐一个珠海的温泉酒店，叫御温泉。

python 都无所谓，当然如果你是跑别人 github 上写好的工具的话，看 readme 的教程使用什么就用什么吧，如果对其中一个系统的不熟悉的话。

@mercurylanded 谢谢，重新去看了官方文档和源码。

加楼主了

最喜欢 f-string 和 type hint 。前者比 format 更舒服更优雅。

不要给函数传入结构体，而是传入所有变量（尤其是超过三个以上变量的时候），这样会让函数更具有可读性。

我也给媳妇买了一台，反馈是键盘手感一般，然后屏幕容易反光（买了个反光膜贴上），别的还挺好。