前端开发单页应用，竟然在 url #后传参， WTF!!!

这有什么关系?

前端的 route 都是这么干的，少见多怪了...

阁下看下 kibana 的，复制一个链接，再复杂的图参数也都配置在里面了。共享非常方便。

这也没毛病啊胸弟，是不是遇到什么实操问题了？

大家都这样吧？。。

@kuxuan 不符合标准啊，很多程序处理直接忽略#后的

@rrfeng 传参为啥不用？ xx=bb。

咦惹 我也这么做 。我感觉自己要死了（有的是为了传参拿值，有的是为了返回上个操作页面
另外 我是个渣渣

@liuzhedash 没有，我不做前端，就是觉得很奇怪。

hashrouter 都是这么干的楼主。。。

我最开始见到 angularjs 这样写也很奇怪

你可以认为 # 后面是一个 virtual anchor 嘛

当然这样的坏处在于当用户关闭 Javascript 的时候似乎整个网站都是不可用的

应该是爬虫的时候#url 传参导致不爽, 跑来吐槽的, 所以应该是站在你的爬虫的角度借规范来吐槽的~ 没有衡量这种方式带来的前端体验

话说爬虫可以借用无头浏览器?

@deepkolos 是的，还特地改了代码，为了兼容这种 url。。。

皇上 大清亡了 手动滑稽

@geelaw 不懂前端，为什么不用?a=b 这样传参，难道因为 nodejs ？

同感， 还好可以用 HTML5 History 模式解决

三年前就很多网站这么用了吧。
单页面应用的兴起应该是有大部分的案例都是用#+path 做前端路由的。
话说我还是喜欢 ECMA-262 的哲学，先让社区用起来再归入标准，毕竟技术也好标准也好都是为需求服务的。

@libook 先让社区用起来的坏处是，大家都自己搞一套，不兼容。最后参照标准的反倒成了众矢之的，比如微软

@oness 问号以及后面的结构浏览器通常称为 Search，服务端通常称为 Query，这部分是会传到服务器的。而井号以及后面的部分浏览器端是称为 Hash，是不会传到服务器上的。
通常单页面应用的路由及页面间的传参不需要服务器处理，也就不需要传给服务器。
最重要的一点是如果在 Search 中传参整个页面是会刷新的，而单页面应用的设计就是想要避免用户在使用过程中页面刷新。Hash 的修改通常就不会刷新。

@oness #15 因为前端不希望刷新页面，例如从列表页进入详情页，直接 js 获取详情页内容然后直接在当前页面显示了详情页，这时候如果变更 url 前半部分会照成浏览器重新加载页面。

当然现在新浏览器支持不重新加载页面变更 url，但是还是老问题，为了兼容老浏览器很多还是只变更 # 后面。

@des 这年头谁赢了，谁就是标准，看看之前微软为了兼容网站，伪装成 chrome。。

@gamexg
@libook
感谢解释，懂了。也是不会产生请求，逻辑处理都在客户端做。

@oness 因为 ?xx=bb 会带到服务端啊，#之后的服务端会忽略，只限于前端用的。

GET 请求这么做有什么不好吗？

@des 我在想可能 ECMA-262 的标准制定流程是完全强依赖社区需求的，所以各家引擎不好为了自己一家的利益或者喜好而随意做草案，反而社区需求以及市场压力会制约各家引擎永远朝着最适应社区需求的方向制定草案。
另一方面也可能是因为 TC39 太勤快了，近几年更新标准的频率很高，使得各家引擎的实现标准不至于会产生太大的区别。

想起以前一同事直接把密码显示在地址栏里，就这样过了 2 年

spa 体验做的好很少，看重的是使用#可以使页面局部刷新

vue-router 和 react-router 都支持 hashrouter

以前 js history api 没有的时候只能用#啊。。
历史遗留吧。

#后面的参数就不是传给后端用的，前端调用后端 api 时还是会老实用？的，你别操这心了。

什么？大清已经亡了！

因为是单页应用啊，后面的参数是前端自己处理的

几乎是 SPA 标准了，不服只能憋着

大哥，标准是会改变的
不要沉迷在 10 年前不肯出来

说到标准，OSI 七层模型说了那么多年，不还是在用 tcp/ip，大家都用的好的才是标准
而且在 Url 后用#的目的本来就不是传递参数，只不过是单页面应用借用这种方式来实现模仿 History api 的行为罢了，等啥时候 100%浏览器都支持 history api 了就没这个问题了

历史遗留问题，而且你要理解这是单页应用

问号不是会刷新页面吗？

?传参走的是 form 提交，浏览器认为 url 变了会刷新页面的，是同步的做法，现在都是异步，查询都是走 XHR 或者 fetch 的，不需要刷新页面，#传参是个大框架都支持的路由传参方法，不过也有缺点，有些第三方 API 默认会过滤#传的参数，导致 redirect 失败，比如微信的 API，号称是为了安全性

两种模式啊，一种 hash 模式，一种 history 模式。hash 模式的#虽然不太好看，但是单页应用路由不刷新必须得这么搞啊。history 模式是 HTML5 标准里的，不少方法还是实验性的，而且 E10 以下不支持。

楼主明明知道自己不懂前端，上来就喷不太合适吧？利益相关：比后端还后端的程序员

@deepkolos 哈哈 刚想说

@libook 正解

不懂前端能不能就不要乱评论

哈，这是前端只崛起

最近的一个项目就是这么做的呀，哈哈，其实目的是单页+返回功能

人家那个是前端自己用的

没猜错果然是后端。

别纠结，这个可以改的

试试不用用 hashrouter 写个微信 spa，带分享得那种。

@xpol 分享出来的 url 需要特殊处理的，这个逻辑判断写死就行

把参数放到#后面就是为了防止参数传到服务器，只由前端来处理

才通网吧

你是绕着弯投诉 V2EX 么？
V2EX 的页面也找不到#replyN 的定位锚，显然也是个传参

少见多怪，技术是不断在发展的，标准也不是一成不变的，当新业务场景出现新技术得已使用，老的标准自然就已经不适用了，有时间还是应该多学习才是

> 如果不想要很丑的 hash，我们可以用路由的 history 模式

vue-router 改成 history 模式

多看看文档就不用问这种问题了

用 # 只是一种方式，有些框架支持随意写 URL，当然 / 这种传统写法也没问题，无非是文件服务器需要配置一些特别的策略
URL 规范？不遵守也一样（当然还是遵守的好）

emmmmmmmm 一般是为了兼容吧。。。

# 后面的内容是给前端做路由用的，如果前端开发想省事那就干他。

#后面是给前端用的啊。前端自己关注就好了。

@younfor 你这个咦惹，让我很有亲切感

如果献丑，可以使用 BrowserRouter，搭配一个十几行 server 代码即可，没必要纠结。

用#hash 还有个好处上面都没提到，就是 http 的 referer 会带上?search，不会带上#hash。如果页面资源多、?search 也很长的话，就会产生许多带有很长?search 的 referer，浪费带宽；而且，带有?search 的 referer 请求外部资源，还有可能把敏感信息暴露给第三方。

全世界都这么做

本来就是为了避免把参数传递给后端才用 # 的……

明明可以用反向代理解决， 非要搞这么一出， 我也不太理解这种做法。

我开 history 模式去了井号, 符合"规范", 你又要开个贴

"前端开发单页应用, 我不配 nginx 还不能运行, WTF"

还有另一个贴
"前端开发单页应用, ie 都不支持, WTF"

无辜躺枪 wtf

@SophiaPeng 你才是大佬 我是渣渣（逃、

世界本没有路，走的人多了。。。

example.com/example.php?action=list 这种算不

服务端可以设置 HTM5 模式的 history 路由，然后访问的话就不会有#号了，像 NGINX。不过#确实不好看，但是方便啊 而且不用服务端做配合设置。

还有可能是为了兼容不支持 HTM5 模式而降级设置的，前端基于浏览器的开发环境是最恶劣的，没有你想象的那么好。

可能会影响到 SEO，不过话说单页面应用就是这样开发的，没问题老铁

这只是降级方案

@rrfeng kibana 自带 url 了，那么长的 url 经常被各种网站解析<a>错

所以说是单页应用呀

@broadliyn #30 不只是遗留问题，当前的微信浏览器对 histroy 模式支持的不是很好！

“碰见和后端一样的东西强行说简单，碰见和后端不一样的东西则强行 WTF ”，你这个心态在众多非前端开发者中很普遍，总是想用后端的思想来处理前端的问题，比如不接受 SSR 以外的任何视图渲染方式。

这也是 React 这种纯粹的前端思想的产物为什么被 VUE 的人气比了下去的原因，以致于 React 为了照顾伪前端和非前端开发者的情绪也出了一套官方的 SSR 方案，一定程度上背离了创建项目时的初衷。

这不是基本操作吗。。。

referer 无法取得#参数？

可以用来防爬虫，网易云音乐的地址好像是酱 sei 的~

angular 和 vue、react 都这样用了几年了，楼主家是刚通网么？

坐下， 基本操作