有时间有精力，就自己跑各大小区公告板挨个打电话看，否则老老实实找中介（必须是成交才收钱的那种中介），那是最便宜的。

你这段代码是要干啥，我真得不想花心思去分析。
length 等于你第一次输入的数值，即 2，那么 arr[2]的时候抛出异常（但你的循环是正常结束的，而不是抛异常）。你这个循环，第一次循环 i=0，然后每执行一次循环体 i 自增。第一次循环 i=0，arr[i++] 即 arr[0]，没问题；第二次 arr[1]，没问题；第二次循环执行后，i=2 ；第三次循环判断的时候，2<length 过不去了，循环就结束了。总共来说，循环结束前，经历了三次 while 判断，两次循环体执行。加上前面代码的 scanner.nextInt()，总共要 5 个。

微信应用本质上就是 web 应用，弄个纯 H5 的 APP 就行了（但是没了微信的魔改，性能会明显下降）。另外，扫描二维码随便找个 SDK 就行（但是用心找的话能减少不必要的权限索取），身份认证这一块需要学习一下 OAuth2 （除非你打算完全抛弃微信上的用户）。

@gadsavesme @Shura 二位高中政治和大学马经肯定是没好好学，房产税肯定是转嫁倒租户，但并不一定抬高租价——价格主要受供需关系影响而不是成本。一线城市不愁没人租的房子自然是抬高房价将房产税完全转嫁给租客——这类房子就算没有房产税价格也会被抬，但这并不是多数。三线之后的城市有大量的空置房（可能是因为投资，也可能是拆迁补助），你要有空置房，没税的时候你宁愿空着也不低价租，有税的时候你还愿意吗？

话说 thymeleaf 跟 vue 不冲突吧。

你这里面冲突的应该是前端路由跟后端路由，或者说完全前后端分离，跟后端 MVC 分离。

如果公司允许你带走纸质笔记，那么它自然也允许你做云笔记，这两者的唯一区别是后者可以复制粘贴。

关于开除那个就纯粹是吓人的：首先，你在任何地方存放公司机密资料，都是违法行为，轻则无偿开除重则报警；其次，公司不能因为你在第三方存放了不涉及机密的工作心得而开除你。这里面的关键是是否存放机密资料，而不是存放在哪里，但中国人就喜欢偷懒的一刀切，所以喜欢直接禁掉你存放东西的工具（当然是只能吓唬胆小的人）。

顺便说一下：一个好的公司，应当购买企业版 OneDrive 或类似服务，提供私有云笔记，而不是禁用云笔记。

不要去平安，见 /t/653545。

能注册、不能登录的。你可以试试登录，秒封。微信的注册本质上就是自主注册+熟人介绍激活（当然表面上不这样说的，而是说你的账号有安全问题必须熟人来解锁）。

还有一点（我可能记不清楚了），Giffgaff 激活的时候，只能用信用卡或实物充值卡，不能用 Paypal （ Paypay 上卖虚拟充值卡但锁区），激活之后的充值，才能用 Paypal。

@tsuad #7 某 Bao

@arry #66 你别告诉我你们系统中基本没有 findById、editById、deleteById 之类的方法。业务变更必然要修改代码，有冲突解决就行了，为了避免将来可能有的冲突而现在不用自然主键，这属于超前设计，现在敏捷开发盛行，已经不受推崇了。你大概没做过更换系统时候的数据割接，那时候只有 UUID 主键是不会冲突的，自增主键和自然主键都会冲突（但是，若提前将主键定位 UUID 也是超前设计，不推荐）。

我推崇 UUID 的原因是它是最省事的主键。自增主键或序列主键都依赖数据库，同时，相比于有顺序有意义的数值，毫无顺序毫无意义的 UUID 才更像 ID。最后那一句就不回了，前面已经说得很清楚了。

顺便提一下，抛开数据库往外面看，git、docker 都是用 UUID 当主键的。

@fancy111 #23 你就这么看不起软件？你试试假如微软被光抓走了，Windows 系统能撑过半年不。

我觉得，非但在当地，你在全国甚至全球想找一个使用 angular 框架都难。谷歌出的东西，通常情况下只有超大号公司才用得起。

正在用，理论上是能长期用下去的，但不敢打包票。
1、能
2、无最低消费，但不能连续数月无任何消费，即必须每个几个月发一条短信来保号。另外每次充值貌似是 10 欧起。
3、暂时无，但就是官网申请的途径走得是国际平邮，且不可写中文地址，基本收不到。

@tabris17 #50 @Lonely #56 两位这是做过什么事，@我是没提醒的。

至于 tabris17 你的回复，你的目光局限到了 InnoDB 引擎上面。热点问题那可不是极端情况，在大数据存储上可是首要问题，关系数据库上热点问题仍然存在，只不过数据量小的时候无需关注罢了，数据量一大照样得使用表分区来避免热点。InnoDB 引擎下若真因为非顺序主键拆分页造成性能灾难，那主因是 InnoDB 引擎而不是顺序主键，难不成 InnoDB 引擎要告诉所有人“我太娇贵，那些用 UUID 当主键的我伺候不了”。

正好又来了 @arry 的新通知，那就一并回复了，性能跟业务逻辑之间，是要做取舍的，不能为了微小的性能提升而牺牲过多业务逻辑的简洁性。现在 InnoDB 要求顺序主键，业务上需要自增主键来自动生成主键，二者正好相互支持。但如果哪天业务上需要把主键换成 UUID 了，要么 InnoDB 引擎能保证性能损失不大，要么就要换掉 Mysql 了。

需要说明一点，本人不是数据库开发者，或者表面是 Java 本质是 SQL 开发的程序员，我推崇的是用 JPA/Hibernate 完全隐藏掉任何数据库细节，并且在主键选择上倾向于 UUID 和自然主键。

即不经常规市场考验（做出来就强卖），又没有御驾亲监（上面要得是面子而不是东西所以也就没花功夫去监察），又不是个人兴趣（做东西的人要的面子、金钱、名望，而不是个人成就，或者真正想要做东西的人被当成傻子排挤掉），这种“国产”，你讨论它的时候，就已经被诓进去了。

实际上任何为了面子的东西，都不要去讨论它。

@xiaowangge #44 一刀切 /懒政规范，就别搬出来了，徒让人笑话。举几个例子：用户表的主键叫做 user_id 是不是违反规范；是用 create_time 同时表示注册时间和记录创建时间，还是用 register_time、create_time 分别表示注册时间、记录创建时间；历史记录类型数据只插入不更新，放个 update_time 字段是不是脱裤子放屁。

@tabris17 #27 你的理解完全反了，顺序主键提高的是 select 效率，但降低 insert 效率。随机写入不需要寻址，不需要考虑重复、乱序、并发等问题，明显要比顺序写入快。

@wangbenjun5 你的理解也反了，单列（字段）主键，从来都不是数据库设计或者数据库范式的要求，而是程序业务设计或者性能优化（更多的是后者）的要求，数据库范式甚至都没要求必须有主键。业务设计上要求单字段主键也是被逼无奈的被动要求。不管是为了识别还是关联，对象总得有 ID ；单字段 ID 明显比多字段复合 ID 舒服多了； ID 不能轻易修改：所以业务设计就给了个不成熟的规范：对象必须有一个业务无关的单字段 ID。这个规范有一个缺点，不是多了个字段，而是对象原本业务相关的自然 ID 被掩盖掉了。总归来说，加一个业务无关 ID，优点大于缺点，所以这个规范就这么用下来了。但是要记住这是程序设计规范，不是数据库设计规范。

提供一个思路（仅仅是思路，不是可行方案）：被点赞方只处理“点赞数”，并且还读写分离（简单的方案就是隔一段时间才根据点赞 /取消事件集中计算最新的点赞数），点赞方（用户）正常处理完整的点赞关系。你只要隔离了被点赞方和点赞方，那么后者是低频行为就无需特殊照顾了，前者也只需要对一个字段（而非关联关系）做高频特殊照固。而只要跳出了 CRUD 的思维，略微懂点领域模型或事件驱动，这个隔离，是不难做的。