把日志记好，出问题好追溯

https://docs.docker.com/engine/storage/volumes/
查到官方文档有相关特性介绍

Populate a volume using a container
If you start a container which creates a new volume, and the container has files or directories in the directory to be mounted such as /app/, Docker copies the directory's contents into the volume. The container then mounts and uses the volume, and other containers which use the volume also have access to the pre-populated content.

看来是个刻意设计的特性...


GPT 问了一圈又一圈没回答到要点, 还是得翻文档才行

啥时候标准库广泛使用泛型改写了，啥时候考虑用，当然也只是考虑考虑

除了上面提到的方式，还可以指定 pod 的 nodeName
https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodename

链接中整篇官方文档正好对应你的问题

无限流量什么意思，你的服务器要抵御阴离子炮轰击? 建议上 AT 立场

先谈剂量，再谈毒性
先谈规模，再谈设计

@lizon 比同事先跑路?那没事了

等你同事的代码上生产了，过了半年他跑路了，你接手了，然后半夜出问题了，领导要你起床马上修复并且上线，还要顺带热修数据，你就会后悔，这么 sb 的写法一眼就能看出问题，当初为什么没有 review 代码提前发现

review 能提前发现处理一些 sb 问题 sb 写法

寻找最佳实践很正常

最佳实践是从过往的工程实践中获得的。最佳实践不一定是当前场景事实上的最优解，但一定是当前有限成本（经济成本，时间成本，智力成本，试错成本，后期维护成本等等）的情况下最值得优先尝试的方案，这个"值得"是从节省成本的角度来说的

如果判断有改进的必要，那可以投入成本改进现有方案，适应当前细分场景就行了

当然理想情况下你可以投入无限的时间成本，经济成本，了解所有细节，设计出一套适应当前情况的最优方案，但是情况又是不断变化的，现在的最优不代表永远的最优，这样做真的值得吗

trade off

插件 Auto-Open Markdown Preview
https://marketplace.visualstudio.com/items?itemName=hnw.vscode-auto-open-markdown-preview

临时添加额外的字段
https://segmentfault.com/p/1210000009960552/read

个人选什么语言跟品味有关，公司选什么语言只有一个原因：生产效率高

https://crontab.guru/

太正常了，环境提供给你的东西和你希望获取的东西毫无关系，人就是个趋利避害的拟合机器，一定会受到身边环境的影响

你能做的就是 尽快 把自己放到自己期望的环境中去。如果环境发生变化，或者你的期望发生变化，切换环境是再正常不过的事，除非你的能量足以把周边环境改造成符合自己期望的环境

时间很贵

阿里云监控，各种指标，各种通知方式都有，自己配

镜像启动的时候使用 -p 参数 先将宿主机的端口映射到容器内，局域网其他机器连宿主机这个端口就行

“未来某个时间触发某推送”是个提前已知的信息，存储的时候就可以先按时间戳升序排列，服务进程只需要从头开始查最前面的记录，下发推送；因为这个信息提前已知，所以可以先将推送信息提前缓存到客户端，由客户端自行触发。
有一个问题是客户端本地时间不一定是准确的，所以服务端仍然需要在特定时间下发推送。由客户端保证推送的即时性，由服务端保证推送的完备性（以免因为客户端本地时间滞后导致推送滞后或者其他原因导致的推送信息 miss ）。

随便说说

@blless 这是个动态结构，你用 golang 试试呢，我没找到方便的做法。[]map[string][]interface{}深入到内部节点还得断言，就没继续写了

再改一次，大晚上脑子不清醒 https://trinket.io/python/dc0a87c0e3