不是说不让你求助，而是说你这样的求助方式完全背离提问的智慧。能犯的错基本上都犯了，教科书级别的令人生厌的伸手党

a. 大神小白道德绑架
b. 直接把问题填到搜索框里就有答案的饭来张口级别的问题
c. 伸手要完整的项目而非问你不会的一点
d. 可能你以为你足够礼貌，但其实非常无礼 错别字 /感叹号 /对回答者提一排要求

建议你自己搜一下提问的智慧好好学习一下，另外学会如何搜索是前提

curl/匿名模式访问一下看是不是有跳转，如果是的话算是苹果官网的安全缺陷

和加入大公司的原因没有什么区别。钱，团队，个人成长

@kimown 十年前的剧本确实是这样的

公司内部用 fork 的价值在哪里？统一发 pr 的话，pr 应该是有意义的，比如新版本 /patch 发布，多不是问题，问题是没有意义吧

分支命名不规范就要求大家规范啊，如果你负责源码管理，那这就是你的锅。发邮件+开会说清楚分支命名要求，然后第二天起不合规范的 request 一律打回，over

不要 bootstrap 对设计有一定需求的话，还是直接 sass 自己撸最快，不要把自己局限成后端前端

人又不是机器，为啥要那么僵硬的用算法来套呢，当然是该广的时候广该深的时候深啦

根本的逻辑不对，应该是根据你想去什么岗位定制自己的简历

open -a 'Google Chrome' --args --incognito

试了一下可以的，不过已经运行的时候无效，如果需要未运行时打开隐身窗口，已经运行的时候新建隐身窗口的话，估计写段 applescript 可以做到

cc @nousername2030

自己往下拉看 example 里 batch 相关的

如果你真的就要离职，那移植应该是 Yii2 那组人的工作，你要做的应该是提供现有系统的详尽文档和在合理范围内答疑配合

如果你完全没打算移植，那这不是在逼你离职么……当初项目开始选框架的时候没有和老板沟通过？沟通过达成一致的情况下还要换？然后现在又“提防你离职”？ 这什么鬼逻辑……正常来说应该是派别的人来学你的东西做 backup 的，哪有这样反过来玩的

一个是看 scope，另一个是看是否 ambiguous，比如 ret res 这种坚决不缩写

result response resource return 傻傻分不清楚

标题和最后一句话是对的，但看代码很可惜似乎并没有理会 mvvm

不是我说啥，我的几个前上司可都比你的好太多了，我提离职以后聊了一段时间确认我的意愿，问了我下家的情况以后就都是祝福了。这种才是真正好的老板，这样以后如果机会合适我一定会考虑再合作的

你这种面对阿里的 offer 还在反复强留的老板（或者更糟都不关心你的 offer 就在留你），有什么好留念或者不忍心的

记住团队核心要走，老板如果 hold 不住团队了，那错的一定是老板，无论是梯队建设、骨干培养、员工情况掌握都一错再错才会出现这样的情况

所以锤子相较板砖有哪些优势？

紧急情况能用板砖敲钉子，有情怀也可以用锤子砌墙，但这不代表锤子和板砖就有可比性了

反正我认识的所有同时体验过 13 15 的人没人愿意下一台买 13，更别说现在带把的 15 又轻薄了一圈，所以按我说这就是预算的问题，有钱就上 15

from=20 相当于 offet=20 吧，我个人的话任何时候都不会做单独这个参数的分页

page （如果需要自定义，加上 pageSize ）的优点在于可读性，尤其是如果再放到 url 里，/products/page/1/或直接 /products/1/，非常清晰

offset+limit （也就是直接在参数里指定取多少，跳过多少）的优点在于便利做加载更多、懒加载、客户端下拉等逻辑（客户端控制维度更细，前提是同步提供 limit ）

至于 cursor，里面的值应该是上一页的最后一个项目的主键 ID，而不是跳过多少条，好处是数据量大的时候能通过索引规避大 offset 带来的性能问题，问题是跳第 N 页会比较难做（实际上数据量一大跳第 N 页一定不好做）

都是图灵完备的语言，只有 JS 上不需要用的设计模式，不存在 JS 上实现不了的设计模式

楼主需要抛开其他所有 OO 语言的经验来看 JS，市面上基于原型链的语言几乎只有 JS 这一家，而几乎没有设计模式或者讨论 OO 的文章会基于 JS 来聊，太多的关于 JS 的 OO 的文章也都是生搬硬套其他语言的做法来误人子弟

回到楼主的比如，比如别的语言里你可能写 interface MyInterface {methodA(); methodB();} class MyClass implements MyInterface {.....} ，实际上在表达的是“给我 methodA 和 methodB 这两个方法，我帮你对接剩余的逻辑”，那么换到 JS 里，直接把接口能力作为依赖就行了

class EsClass {
constructor(methodA, methodB){}
...
}

坑不是程序员挖的难道还能是测试挖的不成？
暴露坑的存在不就是测试的本职么？
测试能跨过界线开始思考如何提升研发质量，那才是真正好的测试呢（不清楚楼主说的超出范畴是不是这个方向）