你说的这些设计，跟 surface 无关，新的 UI 基本都走这种大间隔风格，或者小屏大间隔大屏相对小间隔的自适应风格。Chrome 那种紧凑型的风格，是因为 Chrome 诞生十几年一来都没有整体换过界面风格，那是十几年前的 UI 风格。这种紧凑型的风格，只适合 1366*768 这种坑爹分辨率和 20 寸区间的显示器，在 13 寸一下的小屏和超过 27 寸的大屏上，没法看。

4000 这个挡位，不要锂电池就雅迪，想要锂电池就小牛的非智能系列（基本上都是磷酸铁锂不是三元锂）。可以加钱的话就考虑这俩品牌的智能系列，小牛的智能方案最成熟，但雅迪的工业化程度最完善。

@dxatgp02 #3 先把 public 、private 、protectce 、default/friend 这几个可见范围搞清楚再说。max 声明称 public ，就可以用你的第二种写法。只不过 public 的字段，要比繁琐的 getter/setter 不便处更大。

这是小贷（包括京东金条和各种呗这种互联网小贷）申请时候的查询。如果没有其他记录那就是只查询没后续，所以这个银行那里的一般查询，是查不到你的。高级查询，要查申请但没成功的记录，才有可能查到你。

基本可以确定你被小贷的虚假宣传给坑了，或者没仔细看协议就授权人家查你征信。只有偶尔一次的查询记录的话，除非遇见特别小心眼的银行，影响都不大。

@magic3584 #36 不是直接 push --force ，是先要确定那个人本地的仓库跟回滚前服务器上仓库是同步过的，才能让那个人 push --force 以覆盖的方式恢复服务器上已经被破坏的仓库。

@magic3584 你这一块，我建议不要自己搞了，搞不定的，还是先找别人帮你处理了。后面有时间了花上半个月去看看 https://git-scm.com/book/zh/v2 ，git 才能入门。

@magic3584 #24 假如远程 master 的 提交顺序是 a,b,c,d,e,f,g ，被回滚到了 d ，变成了 a,b,c,d,e,f,g 。这时候 d 之后的提交 e,f,g 就都丢失了。然后丢失的不光是这些，因为这个 e,f,g 在做过 pull 的所有人的本地还是存在的，这时候这些人本地上的 master 分支，跟远程的 master 分支，是混淆的。

实际上中央服务器被回滚，相当于有人做了 push --force ，是特么相当操蛋的行为。这时候要是有人正好在服务器出问题前做过 pull 还好，他那里再做一次 push --force 就能恢复过来。但要是没有这种正好情况，那么在 d 这个提交时间点之后的所有提交，不管是本地还是中央仓库，不管有没有推送过，都成了离线的提交，需要手动处理才能搞回去。

在开发完整软件 /项目 /工程上，JavaScript 确实该入土了。但是在开发脚本上，JavaScript 还是很好用的，比如说 Kettle 上的 javascrpt 脚本就比 java 脚本好用。

JavaScript 的最大问题是它本来只是个脚本语言，却被人用来当成了工程语言，最早拿 JavaScript 来开发客户端应用（貌似是 ExtJS ）的人，应该被拉出来鞭尸。

@magic3584 #18 先 fetch ，你现在本地仓库上的远程仓库引用 origin/master 跟真是的远程仓库 master 分支可能都不一样。这事，建议找熟手帮你做。没有话就别 pull 了，只能手动复制粘贴。

@magic3584 #15 远程分支被回滚，说明远程分支已经被破坏了，这时候就不能做任何 pull ，否则你本地也要跟着被破坏。远程分支回滚后的那个 Head ，它之后的（在回滚前）所有提交，不管是本地的还是远程的，都被搞废了。你们本地需要先留着当前仓库不动，另开位置重新 clone ，然后通过补丁或者复制粘贴，把本地晚于远程 Head 的提交，手动重新提交上去。当然，也可以用 pull --rebase ，它本质上是 rebase -i ，前提是已经对 git 操作尤其是 rebase 相当熟练。

真正的黑客有两种，一种是通过不厌其烦的尝试去找别人程序的漏洞，一种是社工。就算不管这些对技能的超高要求，光工作方式上也是比做生物试验还枯燥的行为，你要知道这些，你不会感兴趣的。那些上新闻的黑客组织，也许有些是真的黑客，但更可能是搜集 /窃取其他黑客的工具进行牟利 /宣传的二道黑客。

push --force ，你是想死吗。你的 1 和 2 都可以，2 并不是本地提交没了，而是因为冲突（本地和远程改了同一个地方），需要你先解决冲突。新手的话，还是老老实实 pull merge 吧。

xx_id 这个索引是有效的，能不能用取决于业务上这个 xx_id 是否是检索条件。

为了分区把 create_time 加到主键之后，这个主键基本上是废了，既不是自然键也不是代理键，很难用。

@chaleaochexist #8 不是同时只有一个事务在执行，而是针对一个数据主体同时只有一个事务在执行。如果操作不涉及插入行，那么数据主体通常是已存在的行，这时候只锁行就行了。如果操作涉及插入行，那么数据主体理论上是全表，但实际上可能不是，因为锁表开销太大了，这方面各数据库都有自己的实现。

原子性是针对当前事务的多个语句的，要么全部执行要么全部不执行，对于当前事务的多个语句执行过程中，是否有其他事务也在执行，它不管，即使是执行的同一条数据。隔离性是针对修改同一个地方数据的不同事务的，不同的隔离级别有不同的表现，最高的序列隔离级别，能保证同一条数据当前只能被最多一个事务读写。

当你是查询和修改已存在数据的时候，可重复读级别就能保证不发生并发不一致问题。但如果是查询和新增数据（比如值为 max + 1 的列）的时候，即使是最高级别的序列隔离性，也不能保证绝不发生并发不一致，因为这时候要想并发一致就得锁表，但为了性能基本上不会物理锁表只能是变通锁表，这个变通锁表就容易漏掉一些场景。

对于你的需求，事务是解决不了并发不一致的。既然你要清空表了，那么最简单的实现就是手动锁表。

@weiweiwitch #21 不测试你约束个蛋蛋。开发是为需求和测试用例服务的，良好的过程中开发更是只为测试用例服务。自我约束这种没有明确目的的玩意，做了是优点不做是正常，不要把可选的优点变成责任。

显示桌面最快的是“ win + D” 快捷键或者触摸板手势

如果你要知道缓存是干什么的，大概就不会这样问了。直接读取最终存储效率不够，于是弄个缓存提高读取效率。所以，只会出现因为数据库效率够了不要缓存的情况，不会出现数据库和缓存合一的情况。

“随着时间的推移，需求的不断变化，开发人员的变动，用户数带来的放大效应。所有各种以前觉得不太可能写出来的、乱七八糟的、难以置信的错误用法都会被人写出来用到项目中，然后引发灾难性的后果。”引起这个的原因，跟墨菲定律屁都沾不上，这原因推起来非常容易：为什么，因为没有全面测试——为什么没有全面测试，因为如果全面测试就要加班——为什么要加班才能全面测试，因为全面测试的东西不在计划内——为什么全面测试的东西不在计划内，会推向一个国人普片翻的错误：只看结果不看过程。