@basefas #11
@eastlhu #16
@zhouwei520 #21

翻了下知乎，翻到了原回答和专栏地址：
https://www.zhihu.com/question/32019460/answer/1268448274
https://zhuanlan.zhihu.com/c_1253290991295655936


BTW：看到原回答下面其实也在讨论二分查找解法实际上是 O(nlogn) 而不是 O(log) 的事儿

很久以前开始用这个插件，支持离线使用：
https://chrome.google.com/webstore/detail/json-editor/lhkmoheomjbkfloacpgllgjcamhihfaj

直接放弃使用指纹…………

https://i.loli.net/2020/06/10/HyOrG8WsFbMB17E.png

@marcong95 #15
固定密钥的 BLE 开锁安全性太差，存在很大的被破解可能。
动态密钥纯 BLE 开锁的技术成本高，需要做相应的密钥体系出来。

所以 BLE 开锁往往需要配合 GPRS 走网络下发密钥。

可以参考下这篇文章：
https://www.jianshu.com/p/c0ed5d3737d4

@Timefly #7
我看了一下，大概看到两个问题
1 、你的 47 行 dfs(nextData .....) 这里，传入的 nextData，里面的 isVisit 似乎没有做处理，这导致 a->h->d->e 这条路径跑不出来。

2 、我只看到你标记了已被使用的路径，但是似乎没有处理重复使用的点，这样还是存在成环的可能，建议用一个 map 直接把已经走过的点存起来，这样就可以不用标记路径的 isVisit 了。

比如说在这样的情况下：
a->b, b->c , c->a

虽然没有走重复路径，但是 a 点被走了两次，实际上已经成环了。

@27 #13
二分查找也需要遍历第一个数字的吧，还有个 O(n) 在外面哇

@longSwordMan #3
对于有序数组二分查找的方案，
因为第一个数字还是要遍历的也就是 O(n) ，
然后查询第二个数字的时候走二分查找需要 O(logn)，
所以实际上总体复杂度是 O(nlogn) 吧

@longSwordMan #3
有序数组的话，可以直接双指针 O(n) 解决吧

[ 1, 2, 3, 5, 8, 9 ], target = 8

1+9 = 10 > 8
1+8 = 9 > 8
1+5 = 6 < 8
2+5 = 7 < 8
3+5 = 8

@Timefly #5
啊，JS 我不熟…… 大概看思路没感觉到太大问题，贴下文本单步调一下看看。


https://gist.github.com/

https://pastebin.com/

https://paste.ubuntu.com/

@abelce #23
楼主写了啊： 『刚转正一个多月』

补充一下，关于场景 3，其实还有一种解决方案是：
当用户被通知开锁失败，点击 『我知道了』 按钮时，再发送一条 『取消开锁』 信息。

但这仍然无法做到 『可靠』：

问题 1 、短信的收取顺序可能与发送顺序并不一致。

如果需要解决，就需要设定一定的缓存机制，当收到 『取消 30#开锁请求』 的短信，却又没有找到 『 30# 开锁请求』 的时候，将取消请求暂时缓存，直到收到相应的开锁请求或者超时再删除。

问题 2 、开锁是个很快速的，而且 『开弓没有回头箭』的操作。
共享单车车锁的一个特点就是，可以通过电信号控制打开，但不能通过电信号控制上锁。
那么即便是两条短信相继收到，只要中间的时间差不是极小，那么收到取消请求时，开锁指令已经执行完毕，无法撤销了。

如果要解决，可能就需要在收到开锁指令的时候，设立 『冷静期』，例如 10 秒后再开锁，但是这样操作好像又让用户多等了不少时间。

有一种开锁方案是基于短信的（我不太确定当前单车厂商是否仍在使用）


以速度排序，常见的开锁方式：
1 、服务端下发短效开锁密钥，手机客户端使用 BLE 方式直接开锁。
开锁成功 / 失败信息，手机和车锁均会返回给服务端。

优点：因为服务端只需要下发密钥给手机，开锁速度贼快
缺点：需要构建密钥机制，存在一定风险，智能锁需要具备 BLE 功能

2 、车锁通过 GPRS 等信道进行 长连接 / 长轮询 / 轮询，根据轮询到的结果执行指令。
开锁成功 / 失败信息，由车锁通过网络返回给服务端，可以直接在长连接里，也可以是单独的 Web API 。

优点：低物料成本、低开发成本，能覆盖绝大部分场景
缺点：长连接 可靠性差，容易退化为轮询导致开锁用时更长，由于连接可靠性差，可能会丢失信息，需要设计相应机制。

3 、服务端直接通过 发送短信 的方式将开锁信息下发给车锁，车锁收到信息时立即执行指令。
开锁成功 / 失败信息，由车锁通过类似的 短信 / DTMF 通道返回，或者通过 Web API 返回。

优点：超强的"可靠性"，能打电话发短信的信号就足够，网络方面成本最低。
缺点：已经发出的短信，完全不受自己控制。短信延迟也完全不受自己控制。可承载的数据量很小。


以上几种开锁方式里，1 、2 两种，开锁任务是可以在消息队列进行管理的。
想要取消一个开锁任务，只需要保证车锁端获取不到即可。

但是 3 就很烦人了，短信形式的开锁指令，你发出去以后压根不知道车锁会什么时候收到。
如果运气不好恰好短信延迟了 3 分钟，就会出现车锁响应了 3 分钟前的开锁指令的情况。
理论上来说，此时应该可以通过让短信中携带失效时间来保证任务不会被超期执行。
但是问题来了：车锁是否具备校时的能力呢？

因为情况 3 是数据网络不好时出现的，那先排除掉基于数据网络的 NTP 服务，
印象中 CDMA 和 GSM 都有授时功能，但是似乎是看运营商的实现的。
所以这里我认为车锁并不能 "稳定的" 进行校时。

综上，消息队列的正确处理，确实能够解决 1 、2 两种场景。
但是对于场景 3，还是有一些困难需要克服。

@Timefly #2
还是贴代码和样例直观一些。

『遍历的路径总有些问题』 具体是什么问题？

是否正确处理了成环的情况？
[ab, bc, ac, cd]
[a, b, c, a, b, c, d]

@hoythan #18
楼主不就是 『直接去 AppleStore 』之后，发现没有解决问题才来抱怨的么？

@hoythan #2
等一下，虽然我也觉得楼主用词比较激烈。

但是…… 深圳益田苹果就是正牌的 Apple Store 啊。
https://www.apple.com.cn/retail/holidayplazashenzhen/

也是深圳唯一一家 Apple Store，打售后电话最后大概率也是引导到这里啊。