Answers:
docker stop是否试图以正确的方式停止在容器内运行的进程，而docker kill将发送kill信号？
基本上可以，区别是细微的，但在命令行参考中概述：
因此，stop尝试通过发送标准POSIX信号 触发正常关机SIGTERM，而kill默认情况下只是终止进程（但也可以发送任何其他信号）：
SIGTERM信号被发送到进程以请求终止。与SIGKILL信号不同，该信号可以被过程捕获，解释或忽略。这允许进程执行良好的终止，释放资源并在适当的情况下保存状态。应当指出，SIGINT与SIGTERM几乎相同。
尽管无论如何都不强制执行，但是通常希望进程能够妥善处理SIGTERM并根据其职责执行正确的操作-由于正常关闭尝试花费的时间比宽限期长，因此很容易失败，这是要考虑数据完整性的问题最重要的（例如对于数据库）；参见例如海顿少校的SIGTERM vs. SIGKILL了解更详细的解释：
收到SIGTERM后，应用程序可以确定其要执行的操作。虽然大多数应用程序将清理其资源并停止运行，但有些可能不会。接收到SIGTERM时，可以将应用程序配置为执行完全不同的操作。另外，如果应用程序处于不良状态（例如，等待磁盘I / O），则它可能无法对已发送的信号进行操作。
docker kill手工关闭以节省一些时间，但是在脚本中，尝试通过以下方式进行正常关闭并非总会更好docker stop吗？我仍然docker kill在脚本中看到很多。
docker kill 将突然停止主入口点进程/程序
docker stop 将尝试优雅地停止它（会礼貌地询问：P）
在这两种情况下，文件系统更改都将保留（在停止或终止时），因此，如果您docker start <container>随后从那里继续进行更改。
docker kill主进程仍在内存中进行任何未决的文件系统更改，则这些丢失将丢失，因此文件系统可能最终受损？
docker kill类似于杀死进程，而不是关闭计算机电源。
类似于将插头从桌面上拔下并关闭计算机
就像拔掉插头意味着硬关闭电源一样，这docker kill意味着直接杀死my_container的方法，后者不会尝试先优雅地关闭进程。
关闭计算机意味着向OS发送信号以关闭所有进程，而这docker stop意味着向SIGTERM正在运行的容器发送信号以正常停止进程。