HTML字符串异常引发WKWebView链接/#!前缀问题排查

这个问题其实和前端的路由机制以及WKWebView的加载逻辑直接相关，咱来一步步拆解清楚：

• 原网站的SPA Hash路由是根源
  你提取HTML的那个网站，大概率是个单页应用（SPA），并且用了Hashbang（也就是/#!）这种路由模式。早年像AngularJS这类框架默认用这种模式，目的是让搜索引擎能抓取SPA的内容（Google当年推出的AJAX Crawling Scheme）。简单说，原网站的前端JS代码会把所有内部跳转的链接，自动转换成baseURL/#!/路径的格式，以此实现无刷新的页面跳转。

• baseURL触发了前端路由逻辑
  当你设置正确的baseURL时，WKWebView加载HTML后，原网站的前端JS会识别到当前页面的基准URL和原网站一致，于是自动激活了它的路由规则——把页面里的相对链接都转换成带/#!的Hash路由格式。而如果baseURL设为nil，WKWebView把页面当成本地空白页面加载，前端路由因为没有正确的基准URL，无法正常初始化，所以链接点击后会变成about:blank#!开头的无效地址。

• 去掉/#!能访问的原因
  /#!后面的部分其实就是原网站真实的后端路径，前端框架用Hash来做客户端路由的映射。直接访问去掉/#!的URL时，服务器能正确返回对应的页面内容，同时前端路由也能识别这个路径并渲染对应的组件，所以就能正常访问了。

如果不想通过拦截请求修改链接，也可以尝试注入一段JS来修改前端的路由配置（比如把Hash模式改成History模式，但这需要原网站的服务器支持对应的路由跳转），不过拦截请求修改链接其实是个简单直接的解决方案。

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