Mac端用DMG更新应用时如何避免替换安装导致本地用户数据丢失

你遇到的替换安装丢文件的问题，本质上和macOS的安装机制设计没有直接冲突，是两个逻辑叠加导致的：

• 你代码中使用的new FileOutputStream("data.txt") 是依赖JVM运行目录的相对路径，当应用在macOS上通过Finder双击启动、放置在/Applications目录运行时，这个路径会默认解析到应用.app包的内部资源目录，而非独立的用户可写位置。
• macOS拖拽式DMG的替换安装逻辑，是直接将旧的.app包目录整体删除，再把新的.app包完整拷贝到相同位置。只要是存储在.app包内部的文件，无论是否是安装包自带的内容，都会被一并清除。
• Windows端没遇到数据丢失，是因为Windows安装程序的默认逻辑是仅覆盖安装包清单内包含的文件，不会主动删除安装目录下的额外文件——你之前存在安装目录下的data.txt，因为不在新安装包的文件列表里，自然不会被改动，但这本质是安装程序的容错行为，并不是这个存储位置本身符合平台规范。

• 如果坚持把运行时生成的文件存在.app包内部，无论怎么调整install4j的打包配置，都做不到和Windows一致的无感知更新体验。因为macOS的拖拽DMG本身没有逐文件比对替换的逻辑，整目录覆盖的机制是系统级的，无法绕开。
• 只要把所有运行时生成的用户数据，移到.app包外部的独立用户目录存储，不需要修改任何安装流程，就能天然实现和Windows一致的更新体验：无论用户选择并行安装还是替换安装，这些外部存储的文件都不在.app目录范围内，安装动作完全不会对其产生任何影响。

• 首先修改代码的路径逻辑，绝对不要用依赖工作目录的相对路径存储用户数据。Java可以通过System.getProperty("user.home") 直接获取当前用户的家目录，不需要硬编码路径：
  • 应用专属的非用户直接访问的数据，存在macOS标准的~/Library/Application Support/你的应用名/ 目录下即可，这是macOS官方推荐的应用数据存储位置，不受应用包替换影响。
  • 如果生成的文件需要让用户方便手动访问，再存在~/Documents/你的应用名/ 也就是系统「文稿」目录下。
• 可以在install4j的JVM启动配置中，把应用的默认工作目录指向刚才创建的独立用户数据目录，哪怕临时保留相对路径的写法，生成的文件也不会再写入到.app包内部。
• 你看到的macOS弹出的“并行安装/替换安装”选择框，是系统检测到新旧包Bundle ID一致时的正常提示，和数据存储位置无关，不需要特意调整流程去掉这个提示。

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