1. 把编译过程写进 dockerfile
- 编译过程是指程序的编译吗？我是写入启动脚本.sh 文件中，编译后再 up 。
---- 指的就是程序的编译（ go build 或者 java 之类的 build ）。编译软件的版本对生成结果有影响，本机编译和环境一致的目标相悖，这是第一个隐患。

2. 把文件夹创建、文件复制过程写进 dockerfile
- 文件复制 我是想区别不大，索性都放在 compose 中方便调试。
---- 不认同这条，可以放弃使用容器了。

3. 编译过程的镜像和运行阶段的镜像分离，使用多阶段构建
---- 补充：多阶段构建和上面第一条有关。

4. 尽量少用 volume
- 少用 volume 的原因是什么？防止文件 io 冲突吗？之前遇到过，所以就复制进容器内了。
---- 跟 io 没关系。具体去看文档

5. nginx 单独容器，除非是做 nginx 功能相关开发
- 项目中有 web 部分，所以 dockerfile 中 add 了安装 nginx ，容器启动时启动 ngixn 。
---- 没有因果关系，“所以”没意义。巨大的单个容器可以只用 docker 没必要 compose 。既然用了 compose ，就要考虑多容器的优势，拆分 nginx 、Redis 、MySQL 等基础组件容器，拆开后也很容易支持动态和静态。

6. dockerfile 或者 composefile 都有 env 相关的功能
- 对 env 有一些逻辑判断，所以写入 sh 。
---- compose 的 env 功能支持简单逻辑。env 只存环境相关变量。少量逻辑放在启动脚本完全没问题。

7. compose.yml 里给每个服务取有意义的名字
- 好嘞
---- 好嘞

初步建议：
1. 把编译过程写进 dockerfile
2. 把文件夹创建、文件复制过程写进 dockerfile
3. 编译过程的镜像和运行阶段的镜像分离，使用多阶段构建
4. 尽量少用 volume
5. nginx 单独容器，除非是做 nginx 功能相关开发
6. dockerfile 或者 composefile 都有 env 相关的功能
7. compose.yml 里给每个服务取有意义的名字

即使写了这么啰嗦，甚至最重要的代码编译过程并没有被容器所管理

十年来第一次见这么长的 command ，真的啰嗦，每一行都在藏隐患

@cmmulxuk 如果理解这几行的差异，就不会写出这样的失误。想解决问题先拿张纸画一下部署的逻辑结构吧，不是随便抓住一根稻草就能救命。

配置里的 upstream 是 443 和 80 端口，日志中的是 upstream 是 8008 端口。
原因就藏在你认为没关系而替换的这几行。

三个 proxy_pass 搞出三种风格：
proxy_pass https://example.com/;
proxy_pass https://example.com;
proxy_pass http://example.com;

这两条日志跟 /ws 路径没关系。

上游也是 SSL ？？ upstream: "https://172.17.0.1:8008/"

8 、平均心率：170 次/分钟

---- 这一档偏高了，适当降一下强度。长距离时降低对速度的追求，多控制跑步过程中的呼吸和步伐稳定性（需要配合核心训练）。
在 1 年-2 年的周期里，逐步增加每月跑步的次数，逐步过渡到每次 1 小时或者每次 10 公里）

小组长小主管就是个大号的打工人。问问看加多少钱

好奇 20 万个字段的 key 都是啥

有个 subtitle.to 的网站可以直接下载

youtube-dl 可以直接下载字幕

下游无限制重试造成的吧。类似的东西，当年抢票插件把 12306 和 github 同时干趴下了。

颈椎病先去做理疗，调理一段时间开始运动，锻炼肩颈肌肉才是缓解颈椎病的最终路径。

做了限制，又相当于没限制

云服务器宕机 2 天？技术方面能不能具体一点

想想我以前刚工作的时候，领导买了技术书给我们看（上班时间可以看）。完事儿还挑重点考，真的是提升最快的时候