CLI应用无需外部数据库能否实现共享状态管理？

每次运行CLI命令都会启动一个全新的独立进程，进程退出后它占用的所有内存会被操作系统直接回收，不存在“程序关停后还能保留内存状态给下次命令调用读取”的实现——这是操作系统进程内存隔离的基础机制决定的，和你选什么技术栈、什么CLI解析库没有关系。

1. 轻量本地文件（绝大多数场景的首选，根本不冗余） #

你觉得存专属文件冗余，其实这是行业内成熟CLI的通用标准做法，完全不需要搭数据库：

• 遵循系统规范放文件就行：类Unix系统存在~/.local/state/你的CLI名称/路径下，Windows存在%APPDATA%/你的CLI名称/路径下，存个简单的JSON文件甚至纯文本键值对就够，读写逻辑加起来不超过10行代码
• 如果只是存isRunning这类服务运行标记，连文件内容都不用写：start命令启动服务的时候在对应路径建一个空的标记文件，info命令直接判断这个文件是否存在就行，stop命令停服务的时候把文件删掉，逻辑更简单
• 这种方案零额外依赖、不占后台运行资源、不需要处理复杂的进程通信逻辑，git、npm、docker这些大家常用的CLI，跨命令存状态全是这么做的，完全谈不上冗余。

2. 常驻守护进程+IPC（唯一能把状态存在内存里的方案，仅适合特定场景） #

如果实在不想用文件存状态，唯一的内存态实现路径是不要让start命令执行完就退出：

• 执行start的时候，让进程作为后台守护进程常驻运行，所有状态都存在这个常驻进程的内存里，同时在本地开一个IPC通信通道（Unix域套接字、本地命名管道、环回端口都可以）
• 后续执行info这类命令时，新启动的短进程通过IPC通道给常驻的守护进程发请求，直接从守护进程的内存里读取状态返回结果
• 这个方案的复杂度非常高：你需要自己处理守护进程的后台化、异常崩溃自动清理、端口/管道占用冲突、IPC通信的超时和异常处理，除非你的CLI本身就需要一个常驻后台的服务来提供核心能力，否则单纯为了存几个状态值用这个方案完全是得不偿失。

• 不要尝试用环境变量存跨命令状态：环境变量是进程私有的，单次CLI调用里修改的环境变量只会影响当前进程和它启动的子进程，根本没法传递给之后独立启动的其他CLI进程。
• 不需要为了存这点状态上嵌入式数据库或者外部数据库：除非你要存的状态量极大、还有复杂查询需求，否则存文件的性能和复杂度都远优于用数据库。

内容的提问来源于stack exchange，提问作者user19025657