我们以 0->1->2->3->4 这个链表为例

朴素法的话：
变量 - 临时变量 n，临时指针 i
循环 - 共访问节点 8 次
i : 0 1 2 3 4 0 1 2
n: 1 2 3 4 5 2 1 0 （ n 先自增记录长度，再 n/2 后自减用于二次遍历）


快慢指针法的话：
变量 - 临时指针 fast, slow
循环 - 共访问节点 8 次
fast: 0 1 2 3 4
slow: 0 1 2

可见，朴素法多了个存长度的变量，快慢指针法多了个指针变量，但双方访问节点的数量是一致的。
不过也可以注意到，朴素法 和 快慢指针法都 做了 8 次指针赋值操作，朴素法多了 8 次长度变量的赋值操作。

其实快慢指针法，本质上就是朴素法变化而来的吧。

我们先来从朴素方法开始：
遍历一遍(n)->计算总数->计算中点所在位置->找到中点(n//2)

这里有个小问题， n/2 很容易计算，但是 n/2 对应的指针地址，该如何取出来呢？

先来最狠的方法，我们继续从 0 开始，遍历到第 n/2 的位置，就找到对应的指针了：
遍历一遍(n)->计算总数->计算中点所在位置->找到中点(n//2)->遍历半遍(n/2)->找到中点指针
时间上，多跑了半遍循环，复杂度层面都是 O(n)，只是常数项从 1 变成了 1.5 而已。

然后我们用时间来换空间试试，把经过的每一个节点的指针都存进数组 arr，最后只需要取 arr[n/2] 就行了。
时间复杂度还是 O(n) ，但是空间复杂度从 O(1) 暴增到 O(n) 了。

然后我们想一下怎么优化，你看啊，我们其实最后只需要 arr[n/2] 这个指针，那我能不能优化成只存储 arr[n/2] 呢？
也就是在遍历的时候，只存储 n 和 n/2 这两个节点的指针，其它的不管。
诶？这不就是快慢指针法了么……

快指针走了 n 步，慢指针走了 n/2 步，算下来，其实还是访问了 1.5n 个节点。
从这个角度来说，大家的时间复杂度实际上都是 O(1.5n)，空间上来说也都是 O(1) ，快慢指针法实际上还多出一个慢指针。

但是…… 很多时候，在计算时间复杂度的时候，习惯用循环的次数来算。
此时，由于快慢指针法的循环可以合并为 n 次甚至 n/2 次，就很容易得出快慢指针法的之间复杂度为 O(1n) 或者 O(0.5n) 的结论，再拿来和朴素法的 O(1.5n) 做对比的时候，就容易觉得朴素法更慢了。

1 、喷点酒精擦一擦触摸板
2 、喷点酒精擦一擦手指头

如果你恰好有一台 mac 的话，可以试试 Apple Configurator
https://support.apple.com/apple-configurator

通过它不止能指定哪些 APP 可以使用，系统内置功能也能一起干掉。

https://i.loli.net/2020/07/26/hEfyLwbBiKkGdQI.png

宝岛 50 元验光

@RiESA
我……… 我就是 NOVA 的付费用户……

去年换了华为以后我特别想死……

第三方 launcher 要不要考虑一下？

当然，想要按键也可以，其实想一下油门刹车就晓得，臭打游戏的肯定藏的有这个
http://amazon.com/Lemo-1640835-Control-Keyboard-Action/dp/B00B3PV47O

https://i.loli.net/2020/07/25/WHYdjJgIwPfVlsD.png

认识一下 FOOTIME FOOT MOUSE
https://www.ergoexperts.com/products/footime-foot-mouse?variant=26314371651

顾名思义，是用脚来操作鼠标的
https://i.loli.net/2020/07/25/1CYXomUA7RFIJ5y.png

@AllenHua #4
你要是夸网页风格…… 我就不同意了，这特么明明就是直接挂了三张图，完全没有任何体验。
好看或许还能说的上，使用体验简直就是一塌糊涂。

体验角度来说，我随便找个天梯图都比它这个好啊，比如下面这个：
http://cdn.malu.me/cpu/

支持查找，支持对比，移动端可以无痛使用，比三张图不知道高到哪里去了……
// 注意，此处仅针对使用体验，无关数据真实性

@inhd #1
@StanMarsh #3
@ostrichb #5
我个人是比较认可极客湾的这份表的，原因很简单，因为他们是真的买了这些机器来做测试。
https://www.bilibili.com/video/BV1hV411C7yL


常见的 CPU / GPU 天梯图等，大部分基于的其实还是网络上直接查到的跑分结果，而不是亲自测试。
自己做测试，虽然仍然无法完全控制变量，但是已经比直接上网查分数进步一大截了。

// 需要注意的是，受限于系统、APP，移动端 SOC 的测试是一定无法做到绝对客观的，只能说使用各种办法尽量接近客观，在我看来，至少目前我没看到更有可信度的移动端 SOC 的性能对比。

我遇到过两次周末面试，都是候选人主动要求周末面试的……

我本来是双休，被迫周末去公司……

然后其中一个候选人还鸽了我，周六下午我一个人坐在空荡荡的公司思考人生……

@hing #32
直接搜 “H310 四网口” 在马云家直接搜能搜到很多啊

@janxin #2

https://github.com/saltbo/goget/blob/ba4b77636c97af44b169d16d8a291989e700bad5/main.go#L49

代码上来看，是会给你选择的权力的……

数据源则来自： https://pkg.go.dev/search?q=gin

6-20 位字符，可使用字母、数字、下划线，需要以字母开头

@madNeal #58
对啊，这不就是我要表达的意思么？

放进 localStorage 的话，XSS 脚本就能获取到（然后发送出去）；
放加了 HttpOnly 的 Cookie 里面，XSS 脚本获取不到了，于是就不会有（能发出去）这个问题。

@ChanKc #41
恩，并不是防止攻击，只是控制损失，其实我觉得这也算是使用 Cookie 来存储凭据的一部分优势。

顺便说一下：
我并不是拥护 Cookie，Cookie 机制也有很多劣势（例如无脑带 Cookie 导致无关请求的体积增大）；
只是说在 『限制 JS 读取凭据』这件事上，Cookie 有一定的优势。

@ChanKc #38
肯定会啊。。。你直接利用 Cookie 的话，利用脚本必须放在你的 xss 脚本里的嘛。
而且必须用户主动运行你的 XSS 脚本才能执行利用脚本，执行次数很有限嘛。

如果不加 HttpOnly，我 XSS 直接偷你的 Cookie 丢出来，我在外面想怎么用怎么用，多方便。

and 其实搜一下 " XSS 窃取 Cookie " 就能找到很多例子……