记得很久以前的时候，我学着用 FontPage 做网页。做好了之后用 IE 打开了网站首页开始欣赏了起来。由于之前没上过网，那个网站就成为了唯一一个我能浏览的网站了。

一个意外的右击让我发现了“查看页面源代码”这个菜单项，点击之后弹出了一个记事本，里面是一些代码，中间夹杂着我网页中的文字。

由于好奇，我更改了其中一些文字，然后保存了那个文件，关掉了记事本，刷新了一下我的网页，神奇的一刻出现了：我更改的内容竟然出现在了网页上！！

“看来 IE 的安全性很差真的是名副其实啊，竟然能让浏览者随意更改网页的内容”，我当时心想。

看了下楼主的仓库，觉得是个挺牛逼的人呢。

加加油找找内推试试。

@Reign 不，我的意思是说那段 Slug 完全不是数据库索引的一部分，可能只是取出数据之后做了一下比较而已。

另外，只用 Slug 来确定数据项的话，用在 Blog 这样数据量小的系统上确实问题不大，但是像 StackOverflow 这样的系统而言，可能会遇到重复的问题。

最后，如果说上面 4 个 URL 中哪一个最好，按照我个人的经验应该是 3 。因为 URL 的中有 SEO 意义部分都在最前面，而且 /符号比较少。

不过我的知识是基于很多年前的经验，不知道现在还是否适用。

其实楼主你关于 StackOverflow 的猜测完全弄错了。你可以试试这个 URL ：

https://stackoverflow.com/questions/42406362/this-slug-is-existing-totally-just-because-we-want-to-make-seo-friendly-url
和你直接访问 https://stackoverflow.com/questions/42406362 的结果是一样的。

从系统设计的角度来说， URL 本身就应该是 questions/42406362 ，后面的 Slug 只是为了 SEO 而已。

楼主， https://github.com/lifei2/interview-1

@paulagent

你要知道，大多数人不会等所有菜都上桌之后才动筷子，而是等三五盘菜上桌就开始吃，同时等其他菜，边吃边评价做菜厨师的水平。

一开始，评价的过程看起来会不太理性——比如有的时候前几盘菜是美味佳肴，大家都做夸赞；而之后的菜就像是甘草一样，大家又会转而不满。

但是只要把菜上完，最终每个人所得到的结论和给齐了菜之后再吃所得出的结论相差并不多。

@lxian2

本来以为只是个同性交友 App ，进来一看没想到真是个同性交友 App 😂

其实这种事应该找个律师问问啊，反正证据都在手上了不着急。

@Muninn

给几段代码比较一下？

我早先用过 Beego ，当时感觉确实有缺陷，但不知道我的“感觉”跟你的是否是一样的。

@Muninn

> 感觉 golang 用 beego 丧尽优势

嗯……想知道丧失了哪些优势？能举个例子么？

如果你的条件是让消息在几十年之后才能取出（ T > N ），而不是（ T = N ）的话， SHA256 是可以到的，不需要其他手段比如区块链。

考虑到 SHA256 的碰撞率大概是 2^(n/2)（ https://crypto.stackexchange.com/questions/3049/are-there-any-known-collisions-for-the-sha-1-2-family-of-hash-functions ），如果你“加密”一条信息（ 0~(2^64)-1 之间任意字节长），如果要暴力破解的话，需要也就是至多 2^(((2^64)-1)/2)次尝试。

假定计算机计算一次 SHA256 需要 10 毫秒（也就是一秒计算 100 个，一天 8640000 个，一年 3153600000 个），你大概需要……嗯， 10^(10^18.4434 ……)年（被省略的那些几十亿年已经不重要了，真的）。

这当然远远大于十几年。别忘了，你可以通过控制消息长度的方法来改变“解密”所需的时间，所以 SHA256 “加密”方法是可行的。

当然，这样也会有意外的情况，比如在这十几年间，有人发明了量子计算机（可以立即解出结果），或者（更可能的）有人发现了更快的 SHA256 碰撞算法（能赶在宇宙毁灭之前“解密”）。

小提示：根据当前的估计，宇宙约共有 10^82 个原子， 10^(10^18.4434 ……)，啧啧啧，超强加密你能行……

同样移动用户，同样饱受 DNS Block 之苦。有些时候 DNS 可以解析（用了 HE 、 3COM 、 OpenDNS 三家的），但很多时候这些服务器完全都无法返回结果。当然 114.114.114.114 这样的国内 DNS 一直正常。

不过后来我就一直挂代理访问网站了（

@hoythan

你有没有扫描过所有的文件？

一个典型的 PHP 程序文件应该以“<?php 开头”。这个标签开始之前不应该有任何东西，包括不可见字符。

当然还有一种可能性，就是你手头上的程序主动输出了那些内容。如果是这样， Debug 会变得很复杂：你需要去掉所有的 Output Buffer 控制（就是让内容直接输出），然后用 headers_list 以及 headers_sent 函数检查到底是谁发送了“ï”字符。

当然，其实如果真是因为主动输出导致出现了 Output Buffer 的问题，可能说明你手头的代码已经很脏了，还是找机会重构吧。

@sammo

> 一些人 我不知道你是故意的还是怎样，总爱把 “一线” 和 “高级工作” 联系起来，实际上是很不准确的，仿佛一周之内 你写得代码越多 自然你拿的钱也越多。

我不太理解你发的帖子具体是什么意思，但是很明显跟我的主题不符。

我只是展示了一份数据而已，并根据这份数据作出了自己的推断。这和你所讨论的问题相差深远。而且我也没有提到“高级”和“一线”。

另外，我个人觉得，经常泡 StackOverflow 的用户，道理上来说应该还是一线或者接近一线的程序员偏多。管理岗位的人大致会去看 Quora 或者 LinkedIn 吧？（我猜），所以就这份数据而言，准确性还是比之前那些猜测靠谱的。

当然，不知道 SegmentFault 之类的国内网站是不是也有兴趣做一下这方面的调研。 @segmentfault

@loserwn

> 对于华为内部，很多时间长的「老员工」，确实存在混吃坐等股票分红收入的情况。

你说的是“混吃等死”的情况，只是这些“混吃等死”的人恰巧年龄比较大而已。而不是说工龄长就是混吃等死的。

其实很多人年轻的时候就开始了混吃等死，只是由于种种原因表现的不明显而已。

@hoythan

后面是 C3 AF C2 BB 么？仍然是 BOM 头，只是转换过。而如果是 EF BB BF 则是没有转换过的。

https://en.wikipedia.org/wiki/Byte_order_mark

我可以猜想你当前看到的代码应该很乱 :D

想要解决这个问题，你可以写一个扫描器枚举所有目录，然后找到所有前三个字节是 EF BB BF 的文件，把这些文件从新用 UTF-8 Without BOM 存一下就行了。

https://secure.php.net/manual/en/class.directoryiterator.php
https://secure.php.net/manual/en/class.filesystemiterator.php

Good luck 。