这确实是Java企业级应用开发里非常常见的一个痛点，咱们来一步步理清楚问题和解决方案：

为什么打包在jar/war里的mydata.txt没法写入？ #

你遇到的问题本质上是应用包（jar/war）是压缩归档文件，运行时类加载器是从这个压缩包里读取资源的，而不是直接操作磁盘上的独立文件。不管是getResourceAsStream()还是官方不推荐的getResource()/CodeSource方案，都没法实现写入：

• getResourceAsStream()本身就是只读的，只能读取压缩包里的资源内容；
• getResource()返回的URL可能是jar:协议的路径，指向的是压缩包内部的条目，根本不是可写的文件系统路径；
• CodeSource方案依赖JVM的类加载实现，不同应用服务器（Tomcat、WildFly）的行为可能不一致，而且生产环境里很多服务器会限制这类权限，完全不可靠。

临时目录为什么不适合存关键数据？ #

你说得对，java.io.tmpdir指向的临时目录绝对不能用来存关键数据：

• 操作系统会定期清理临时目录，服务器重启后数据大概率丢失；
• 如果是多实例部署（比如Tomcat集群），每个实例的临时目录是独立的，数据会出现不一致的情况；
• 临时目录的权限通常比较宽松，存在数据泄露的风险。

企业级应用是不是绝对不能用文件存数据，必须用数据库？ #

答案是不是绝对，但关键业务数据优先用数据库，分场景来看：

优先用数据库的场景 #

如果你的mydata.txt里是结构化的关键数据（比如配置记录、业务日志、用户操作记录这类），强烈建议迁移到关系型数据库（MySQL、PostgreSQL）或者NoSQL数据库（Redis、MongoDB）：

• 数据库支持事务、持久化、多实例共享访问，能保证数据一致性；
• 自带备份、恢复、索引等功能，运维成本比自己管理文件低得多；
• 应对高并发、分布式部署的场景，数据库的方案成熟可靠。

可以用文件存储的场景（但要选对方式） #

如果确实需要以文件形式存储数据（比如非结构化的文本、二进制文件），也不是不行，但绝对不能放到应用包或者临时目录里：

• 指定专用的固定数据目录：在应用配置文件（比如application.properties）里配置一个明确的路径，比如app.data.directory=/opt/my-application/data，应用启动时先检查这个目录是否存在，不存在就自动创建，然后用普通的FileOutputStream或者NIO的Files类来追加写入；
• 分布式部署的话用共享存储：如果是多实例集群，这个目录要挂载NAS（网络附加存储）、分布式文件系统，或者直接用云存储服务，保证所有实例都能访问到同一个文件；
• 权限控制：给这个目录设置合适的读写权限，只允许应用进程访问，避免数据被篡改或泄露。

给你的具体建议 #

1. 如果mydata.txt里的是结构化关键数据，直接迁移到数据库，用JDBC或者MyBatis、JPA这类ORM框架操作，完全解决写入、追加、查询的问题；
2. 如果必须用文件存储，立刻放弃写入jar/war的想法，改用专用的固定目录，通过配置文件管理路径，保证数据持久化和可访问性；
3. 绝对不要用官方不推荐的getResource()/CodeSource这类hack方案，生产环境里大概率会出问题，而且排查起来非常麻烦。

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