我有一对PathBuf对的列表，我想生成能够提供有效映射功能的代码 - 查找路径并给出对中的相应路径。为此，我使用phf创建一个静态哈希映射。
我目前的实施是pub static PATH: phf::Map<&'static str, &'static str>。我有一个访问函数fn lookup(path: PathBuf) -> Option<PathBuf>，可以将PathBuf解包到str中，执行查找并将生成的str包装到新的PathBuf中。我使用to_string_lossy在代码中生成路径的字符串表示，目前工作正常，但显然不稳健。
我认为放弃将生成的代码中的路径完全表示为字符串并转而使用例如序列化为[u8]可能是明智的。 bincode以确保表示是健壮的。
是一种明智的做法吗？是否有一种安全的方式可以保持＆＃34;自然＆＃34;字符串表示？
尽管我在下面来回徘徊，但我仍然站在栅栏上，问题仍然存在：我应该使用bincode序列化我的对象并将二进制文件放入phf::Hash或直接存储对象。 前者感觉不必要的开销（但使用bincode可能很少）。后者感觉很脆弱 - 我必须在PathBuf周围实现一个包装器类型来获取散列并实现Debug，以便在代码中提供正确的表示 - 以及如何确保我不确定。
你不能使用
使用的基础表示OsStr吗？毕竟它是PathBuf
让我意识到我正在为自己创造更多的东西。我通过直接编辑代码而不是更改代码生成器来测试。因此我使用的是phf宏而不是代码生成器。使用代码生成器，我得到一个很好的清晰错误消息。
我可以直接使用PathBuf但需要为其编写PhfHash impl。为避免孤立实现，我需要在其周围放置一个类型包装器。
但是，OsStr并未对其表示做出任何保证。 as_bytes仅适用于Unix。 OsStr和PathBuf确实实现了Hash。
phf文档说明了PhfHasher：
这与标准库的
Hash特性不同之处在于PhfHash的结果必须独立于架构，以便在交叉编译时哈希在主机和目标之间保持一致
...因为我生成的代码依赖于（相对）路径在编译和运行之间保持有效，我认为这不是一个问题，我可以通过转发到{{PhfHash来实现1}}。
尽管我担心如何以健壮的方式序列化Hash，但phf实际上只依赖于使用PathBuf进行格式化以将密钥转换为生成的代码。
我想也许是时候我不再担心并且为了代码生成而接受Debug。但是，OsStr的Debug实现不会生成Debug的有效代码表示，而只是打印一个字符串（Debug是手动实现的，而不是派生的）。我的OsStr包装器还必须实现OsStr来生成结构的有效代码表示。