@ichubei 1w pv 5 块算低的了，我了解的 10 块-30 块都正常

@cdlixucd 解决方案就是多个小文件合成大文件 降维 减少 I/O 开销，推荐可以试试 pika 或者 ssdb，优势是支撑几 kw 问题不大 内置分布式 也不用自己维护同步 弱点是性能只有在 ssd 下才能体现 如果要求不高 普通硬盘也可以试试

@kisshere 文件多了都会在 I/O 上有瓶颈 无论是 rsync 还是 lsync 底层是绕不过的

机器之间同步太耗时耗力了，而且如果是异地机房同步的话尽早放弃吧。

比较节约成本和省事的办法：

1. 将源图存 qiniu 或者 oss 三方存储上
2. 部署 5 台 CDN，使用 nginx 反向代理至图源，并本地缓存
3. 用 nginx 缓存管理，设置热数据存储大小就行了

这方案扛千万或者亿级数据问题不大，更大的话提供不了参考。

相信我，inotify 文件多了，每次机器重启或者服务重启 I/O 会卡到你怀疑人生。

目前比较实用的方案就是用 K/V 方案存 leveldb 类似的产品（如 ssdb 或 pika ）做集群。

29 岁 80w
30 岁 120w
31 岁 300w

机遇和处境在 30 岁上下会有大变化
如果你懂得抓住机会的

@veike
你好：
1. 权重问题，用 article/id-page.html 影响的是 /article/ 目录的权重，如果你想 /article/ 有好的排名，你就必须得走 /article/id-page.html 的文件形式让文件输出权重给目录。而且，对于长尾词，html 后缀权重更高。P.S. 当然，我举的例子只是方便让大家理解，并不代表就是实际是这么应用的。
2. 层次问题，全走 / 或者全走某个 - 或者 _ 之类的分隔符，意味着你站点的层次不够清晰，SEO 并非空穴来风，层次清晰的数据才是他们判断优质网站的标准。P.S. 我没说层次不清晰搜索引擎就不会有好的排名了，只是需要的时间更久而已。
3. 收录问题，目录层级越深，收录所耗的时间越长，但是单纯的追求浅层次的 URL，代表站点内容单一，久了也不一定会有好的排名。

在路由这个简单的问题上，我对度娘实战的经验、思考和理解不止于此，介于篇幅，先做以上通用的解释吧。

@kisshere
为什么要怕？大家愿意把我当笑话看，我十分荣幸。技术怎么解决路由不重要，我也知道有一万种方式去解决。但包括你在内，大部分人都认为这两个 URL 在 SEO 里没区别。我不想过多解释，也就笑笑，我想这也是为什么很多大牛不愿出来交流的最终原因。

感谢楼上各位的建议，受小弟一拜~

只是，大哥们个个都用 2019 年来说事~

小弟我想说，既然都承认 2019 年了，为什么一定要去断定某件事情对与错呢？

SEO 没有实战结果的大哥，可以说你的见解，讲你的故事，但是评价甚至抨击他人的对错是不是过头了点哈？

我花了 2 年时间，一点一滴的思考，如何做好每一个环节。

目前凭个人能力养活了：月活 2 千万 UV，3 亿 PV 的站群，如果这算是错误的话，我愿意一直错下去~

当然，这也只是互联网的一角罢了，比小弟搞 SEO 的大牛多了去，只是不愿意露面罢了，

大家没必要自己做不好 SEO 去就去 BALA：

别玩啦，整不好的。

这技术 2019 年没用啦。

等等

只是因为你没有花心思，没有在这领域里细心钻研，仅此而已。

最后，我还是那句话，只是简单吐个槽：

框架有时候并非万能，也不一定就是你想要的。

谢谢各位，见笑了。

谢谢楼上各位对小弟的 SEO 指导

1. SEO 不是改个路由就能上天的，后边需要的是合理结构、优质内容、完整的用户体验来支撑。
2. 靠 SEO 财务自由的人不少吧，说 SEO 没用的，只能说没有接触到它的精髓。
3. 关于 Vue 路由那个例子，也许很多外行看来 /dir/{id}/{page}/ 和 /dir/{id}-{page}.html 其实是一样的，建议仔细去了解一下。

小弟做站群 4、5 年，规模几百个，最近想重写一部分架构，调研时遇到了这个问题上来吐个槽而已

我并非带有任何情绪，想否定任何人或团队的作品来提升优越

通用框架这东西，和真正做项目在实际应用中有时候差得太远

为了兼顾易用和扩展，牺牲了精细化和性能，

所以，更多的时候我会去思考，对于框架，到底需要他来做什么事。

图片检索 mysql +redis 就够用了 simhash 分段检索 降维 轻轻松松 实在不行可以上穷人玩的 sphinx

@mikoshu

我也在 google 上找到过这个，确实兼容浏览器，

但是这个初衷用来判断 css 是否正常加载，

加上 try , 改改勉强可以用，但效率实在不高...不如方案一了，so...

@johnnyNg 是的，这个方案就是方案一。

目前是按这个方式做的，不过不是 fetch css 太费劲了，js 会好一些。

如果能减少这个请求，用其它不知道会不会有更好的体验。

@Tomorr 感谢🙏 之前想过 但是因为不一定是 SPA 应用 会导致每个页面都需要 perfetch （或缓存）。 假设只有 10% 的用户会加载失败 意味着需要牺牲 90% 用户第一次打开的体验

@mytry SW 方案是可行的 但是目前不稳定因素有点多 也无法做到优雅降级 所以…还是非常感谢提供的信息

@opengps 其他疑问我在楼上解释了一下。老哥优秀～考虑的比较远哈，域名多样性，服务器稳定性会做为第二步继续考虑…只是第一步都还没解决…

@Tomorr 老哥 看了代码 你这个只能做接口的 fallback 没法满足我这需求哇😂

@mytry 老哥 你这个应该和我的需求差不太多 但是感觉写文章理论偏多 实际应用上还有很多细节没考虑到呃…

@zephyru 不一定是快速展示页面的需求 就像上边二楼老哥说的 而应该算是一个 fallback 的备选方案；相比如果用 dns 做负载的话 生效时间有延迟。如果用 nginx 做负载的话 不一定能实时检测出用户和服务器网络是否通畅。所以才会想出这样的方案