@zhou00 就美国和加拿大而言，号码规则是一样的，都是 NANP 标准。其他地区不了解，但各开发标准都建议使用 E.164 格式。所以你这个需求是不是可以精剪一下？

看你到底想干什么了，为什么必须要区分美国还是加拿大？
如果核心是国家，那就存国家，然后根据国家取区号。
如果核心是区号，那就存取号，然后把所有国家都显示出来（如：美国 /加拿大）

PS：区号本来就不是与国家绑定的，还有一个国家多个区号的呢

函数式编程一般不删，直接 oldArray.filter(i => i.date > someDate)，返回一个新数组

黑号是正解，这不是杀熟

有没有证据证明他把公司的钱私用，或是注册资本未足额缴付的？否则没法执行个人财产啊。

如果你用的是那个永久免费主机的话，那不可能实现永久免费，来自中国的流量很贵。套了 CloudFlare 也会有来自中国的流量

@fxxkgw #41 绝大多数智能门锁都是控制外侧把手与锁体之间的通断，具体开锁还是靠你的力气，否则什么电池也用不了两年啊

阿里云没有对标 Cognito 的产品么？

公交卡的原理与各种 Pay 一样，都是软件模拟一张 CPU 卡，与你用的银行卡一样。所以软件不支持，就不能用了。

门禁卡原理更简单，就是每张卡都有一个全球唯一 ID，把这个 ID 录入门禁系统的白名单，就能用来开门了。所以只要物业配合，录入你的公交卡、银行卡什么的都可以。我就是一张公交卡走天下，家里和公司的门禁都绑定这张卡，很方便。而手机模拟门禁卡，就是把自己的 ID 改成与门禁卡一样就行了。

但是，门禁卡虽然原理简单，但卡 ID 是卡的唯一标识，有国际组织管理的，理论上不能随便改（当然，实际上在中国没人管，复制卡满天飞）。所以手机想要修改自己的 ID，都需要 root 权限，你要是能 root，那装个第三方软件就可以随便改（注意软件支持的硬件，一般恩智浦的支持比较广，其它 NFC 模块不太好找软件）。不能 root 的就只能指望手机官方支持了，手机官方支持的门禁卡复制功能都很谨慎，又签协议又限量，还反复确认。

@xnth97 巨硬这个看着不错，下个项目试试。但似乎没看到 tab 控件呢？

看了大家的评论，我觉得还是 Huawei 聪明。彻底不开放 root，大家就不骂了。

@leewi9coder 佳佳的插件系统与 sublime 类似，但就我常用的插件而言（ xml 和 json 格式化，base64 编解码）佳佳的都比 sublime 方便

@liuidetmks 没事，我整个电脑都是 win2000 风格的，直接在 windows 里禁用皮肤和特效。

我只需要我女朋友漂亮，其他的都不用漂亮。

我只需要跟我女朋友慢，其他的都越快越好。

早已换了那个不能说的佳佳，不仅免费，各种插件也比这个好使

@xulolololololo 一方面是习惯问题。打个不恰当的比方，玩相机的人都有一堆镜头，大部分人只习惯自动头，但有些人也习惯用手动头。其实无论手动头还是自动头，其核心原理（透镜成像）都是一样的，不一样的是外围辅助功能。

但手动头有手动头的好处，比如便宜，买一个自动头的钱能买好几个手动头，或者同价位的手动头成像质量比自动头好。

所以你如果能习惯手动头，你眼前的世界就会比别人更大一些。但如果你只想用自动头，也可以，但最好能先彻底理解一下自动头的工作原理，否则有问题你也不知道为什么。更有可能你压根发现不了问题……

@xulolololololo 传统数据库很多你以为的筛选，其实也是扫了全表。

看上去你对数据库的工作原理不是很了解，这种情况就更应该学学 DynamoDB 这种把所有本质都暴露出来的数据库了，对你使用别的数据库也有好处

@xulolololololo 这还是个习惯问题。

DynamoDB 的目标很单一，就是快，为了快，它舍弃了很多传统数据库系统提供的功能。

就拿你说的那个排序问题为例，你觉得传统数据库是怎么实现排序的呢？无非也是两种——要么全读出来再在内存中排序，要么用那两个字段建个索引。你现在采取的是“索引法”，如果数据量不大的话，也可以全读出来，然后在内存中对结果执行排序算法。

看，DynamoDB 是不是跟传统数据库一模一样？只是把原先水面以下的东西拿到了水面以上而已。或者说，为了快，舍弃了传统数据库提供的包装。

其实这还算好理解的，个人觉得 DynamoDB 与传统数据库最大的区别在于数据的组合。传统上我们会用多表 join，但 DynamoDB 不好 join，只能多次查询。这让习惯传统的程序员很难受，如果你们公司有 code review 的话，一定被骂过查询太多，要求优化。

但 DynamoDB 不一样，因为它快，而且是 serverless 。这意味着我们可以同时发起成百上千个查询请求，让成百上千台服务器同时给我们干活。比如你要想把订单和用户信息组合在一起，那就先查订单，然后用异步 /协程 /多线程去同时查询这些订单里的用户 id 。不用怕，这比传统 join 还快，关键是不会形成瓶颈，就算某个查询慢了，也不会占着资源影响其它人。

AWS 深度用户路过，没用过阿里云的对应服务，但 AWS 的 Serverless （ Lambda+DynamoDB+APIGateway ）很对我胃口。

一开始确实如楼主所说，不符合传统开发习惯，但习惯以后再做传统项目，就觉得这也不爽那也不爽。所以这只是个习惯问题，没什么好坏之分。

不过没什么好坏之分是指的开发，若需要开发兼运维，那还是 Serverless 爽。尤其是云服务器，访问量稍微一大，就开始各种各样奇怪的毛病，很多是云服务器低下的 IO 性能，甚至是低配服务器被母鸡故意闲置资源所致。而 Serverless 就没有这些，还省个运维的人工成本（程序员免费加班兼任运维工作的那种公司不适用）

新建一个 userid 表，第一列是原始 id，第二列是目标 id，默认情况下两列一样，合并后的就不一样了。

查询时 join 这张表。