我已经在 JVM 和 Rust 的库中实现了此类功能。这是我学到的：
处理应用程序名称，因为您的用户不能或不会。
提供计算配置、缓存等目录的完整路径（包括应用程序名称！）的 API。不这样做将导致代码在 3 个主要平台中的至少 2 个平台上保证是错误的，因为约定差异很大。
考虑一个名为 Foo App 的公司 MegaCorp（网址 MegaCorp.co.uk）编写的应用程序。
在 Linux 下，命名应用程序的路径段应为 fooapp/（小写，无空格），在 Windows 上应为 MegaCorp\Foo App\（注意 两个 文件夹），在 macOS 上应为为uk.co.MegaCorp.Foo-App（无效字符替换为-）。
例如，我的库在 macOS 或 Windows 上不提供 runtimeDir，因为 XDG_RUNTIME_DIR 与 e 非常不同。 G。 %TEMP% 在 Windows 上。
这是一个潜在的安全问题来源，因为 Linux 上的运行时目录保证它只能由所有者访问，在用户注销时被删除，等等。
另外，我只在 Linux 和 macOS 上提供 fontDir。 Windows 确实有一个字体目录，但与 Linux 和 macOS 不同，它不是用户可写的。
另一方面，我在所有三个平台上同时提供 dataDir (%APPDATA%) 和 dataLocalDir (%LOCALAPPDATA%)。在 macOS 和 Linux 上，这些目录返回相同的路径——这是一个明确的设计决策，考虑到如果其中一个目录不可用，用户将如何编写代码：用户要么忘记处理它，要么只是退回到另一个目录。使用所选择的设计，这只是开箱即用，用户无需考虑。
在用户遇到问题之前避免问题。
这就是为什么general cache, config etc. directory paths返回%LOCALAPPDATA%和%APPDATA%，但application-specific cache and config directory paths返回%LOCALAPPDATA%\Company\Application\cache和%APPDATA%\Company\Application\config。
注意子目录！这是为了保证应用程序的缓存、配置和数据目录的清晰分离，无论用户可能有什么奇怪的 Windows 设置。
将用例拆分为单独的模块。
我的库中有三个不同的模块，具有明确定义的独立用例：
BaseDirs，查询用户不可见的标准目录（缓存、配置、数据、可执行文件、运行时目录）的路径，强烈建议改用ProjectDirs。
ProjectDirs，为您自己的应用程序或项目计算缓存、配置或数据目录的位置，这些目录派生自标准目录。
UserDirs，查询面向用户的标准目录（音频、文档、下载等）的路径。
虽然BaseDirs 和UserDirs 有相当无趣的构造函数（new()），但ProjectDirs 提供了这个工厂方法：
ProjectDirs::from(qualifier: &str, organization: &str, application: &str)
此方法可确保用户最终获得指向其应用程序缓存、配置等目录的正确、符合标准的路径，而无需了解每个单独平台的所有复杂性。
最后一个建议：我会保留一个名为“XDG Basedir Library”的库，专注于 Linux，并发布一个更通用名称的库，如处理 Linux、Windows 等的“标准目录库”以避免混淆.
希望这对您有所帮助！