其实这种的问题估计还是完全做的掩蔽很难，你做出来了，人贩子学的也很快，应对太简单了，比如走出一点就会搜身，不具备门槛，这样的话就没用了，而且地下室、偏远地区，更甚人贩子会有专门的屏蔽安全屋之类的，完全没用，如果只是想离你远一点就报警，那么手表是最好的，现在也有很多人做这个了吧

硬件上来说，做到硬币大小应该是没问题的，iot 设备也很省电，普通 gps+gprs 方案，平时完全可以关闭 gprs，gps 的话，只需要快速移动的时候提高扫描频率，平时分钟以上扫描，估计撑个一个月也没啥问题吧，真出事有 gps 帮助，两三天了还找不到，那啥也别说了，所以这不是个技术问题

效率低，入门门槛高，招人换人麻烦，大多框架配置文件怎么写都得看三天，费劲死了，部署发布还麻烦，要有这时间 php python 都快做完了

另外弄个小发送服务呗，用 grpc、thrift 啥的弄个也很快了，几分钟就搞定，单量少，也就不需要考虑那么多了，加到 supervisor 进程管理里，很简单了

或者更简单的，另外写个接口发送通知，再用 fscokopen 构造一个 http 请求，但是不等待返回就是了

如果只是 4 到 5 项索引，写性能影响不大吧，除非你写特别多，如果每秒过千的写，估计也不是单表千万数据的问题了
千万级别对 mysql 数据真不算大，如果索引超过内存很多，倒是可以多加点内存，索引和查询缓存的效果还是很明显的

@jimmy #70 忽略不计，既然是梯子，这点流量就算 cpu 计算影响也可以忽略不计了吧

@warcraft1236 #4 感觉都有可能，考虑的话，可以换个端口试试

被干扰了？阿里云香港 https 也会发了 client-hello 之后就没反应了，连接不会断开，但是啥也不会返回

只绑定了 127.0.0.1 ？

@zealic #19 内存使用量算错了吧，算法也不对吧，否则 mysql 索引应该早做成这样了，这么大数据量，想查询快，怎么也得几百 G 内存使用的吧

@stiekel #25 想了下，如果 500 亿的话，极限情况估计需要 6.2T 磁盘不小啊，前四到五层也许可以直接放到内存里，但是查询是稳定可靠的
排序后遍历 16 次就可以完成 trie 树构建，还是有点麻烦的，如果频繁查询也许还是不错，偶然用一下感觉还是 grep 来的更快更简洁吧
如果想读磁盘更少的话，可以每层保存两字节，8 次就可以，单每次读取量大大上涨了

trie 树存储呗，内存不够就序列化到磁盘，看你这个 32 位字符串都是 16 进制编码的吧，直接解码成 16 字节，查找磁盘最差也就 16 次，缓存开始几层，应该不慢

@WordTian #2 明显是现在小孩早期营养更充足发育更快，而且以前带小孩不像现在这么细致，现在婴儿能接触信息更多，学习速度更快，但是是否更聪明倒是未必吧

@boycottangent #20 教育水平更高，掌握知识信息更多，相同测试必然更好吧，这也不能说明什么啊

@ooooo #65 人脸解锁人家是操作系统做的，有专门硬件支持，驱动层优化，一 app 层面怎么可能做到，要是可以这是多大的安全问题，在使用场景这么广泛的情况下，根本不可能有这种基本的错误

电视电影都是可以黑天黑地的，想干嘛就干嘛，但是现实世界都是讲成本收益和风险的

@ooooo #54 首先这是手机，标准设备啊，不是你自己造的智能音箱，你要是能实现不开录音还能检测环境音量，那才是见鬼了，是不是随时录音确实可以从电量看出来，积少成多，很明显的，而且录音解析语音的话，cpu 完全不能进去低功耗模式了吧，这耗电不蹭蹭的

但是这种事情，都是做技术的，怎么感觉谁信谁傻啊

@jimmy #14 仔细看，cpu 还是高很多的，原生差不多%2-%5，而梅林动辄 10%了，跑飞 40%-50%，而且可以看看日志，ppp 服务好像会不稳定，容易挂掉

梅林用了一段时间，后来还专门去翻了翻源码，全都是 c 写的，感觉不太好用，总是有进程跑飞，稳定性太差了，现在想想还是原版省心省事啊