继续讨论来自 Discourse 重写 URL 路径行为因子文件夹而失败：
我遇到了上述主题中完全相同的问题，即 URL 仅在子路由的开头与子文件夹相同时才会被重写。我使用 /f 作为子文件夹，我了解这种设置的局限性和麻烦，但其他一切运行正常，因此如果可能的话，我希望得到帮助来修复此问题。
我并没有使用现有的 Discourse 路由，但如果单字母子文件夹确实是个问题，我想在考虑更换其他方案之前先尝试修复它。
以下是一些被错误重写的路由示例：
/f/t/food-chain-magnate/4826-\u003e/f/tood-chain-magnate/4826/f/tag/food-chain-magnate-\u003e/f/tagood-chain-magnate/f/u/renato/follow/following-\u003e/f/u/renatoollow/following/f/u/fred/summary-\u003e/f/ured/summary
由于这是客户端的重写，使用 CURL 请求相同的 URL 则能正常工作。
这是最初修复此问题的提交，但 getURL 已改为使用 get-url 辅助函数，而非 Discourse.BaseUri。
追踪对 getURL 的调用后发现，在第一次调用时 location.pathname 是正确的（以 /f 开头），但在随后的某次调用中，子文件夹被剥离，变成了 /t/f-started-slug/id，导致 这个替换操作 错误地作用于该 /f。
我对 Discourse 的内部机制了解不够，无法完全理解此重写发生的具体位置，但在我的实例中测试发现，强制 withoutPrefix 中的替换操作仅在 path 的开头生效似乎可以解决问题。
// 将 ... 修改为
return path.replace(rootURL, "");
// 改为类似以下代码 ...（假设 rootURL 不需要转义）
return path.replace(new RegExp("^" + rootURL), "")
// 或者不使用正则表达式 ...
return path.indexOf(rootURL) === 0 ? path.slice(rootURL.length) : path;
我不确定这是否是一个可行的修复方案，或者是否会引入任何回归问题，任何帮助都将不胜感激。