@ThanksSirAlex 对，去大厂面试是最有效的检验方式。

30k 封顶，只招 p6?

税前年收入除以 12

10k 到 12k，入门
12k 到 20k，初级
20k 到 35k，中级
35k 到 60k，高级
60k 到 100k，专家
100k 以上，资深专家

级别都是市场定的，知识深度或者广度只是多个纬度中的一个

@wu67 我们也没有过均摊的算法

然后一个硕士下嫁洗碗工吗？

比 Java 技术栈危机来的更早的，是各位的中年危机

证明自己是自己，是个难题，有时光有身份证都不够

淡黄色底 34 号字，白底太刺眼，黑底由于眼睛散光看着累

pull 的时候做了 rebase

LGud58，最便宜的时候 2000 左右

@zhaogaz cpu 时间片通常是毫秒级的，lock free 持有锁到解锁之间的时间间隔通常是纳秒级的，在 A 线程占用 CPU 的时候，他都够锁和解锁上百万次了，lockfree 并没有带来更多的上下文切换。

我不点 40 块以内的外卖，每次都选很多连锁店的大品牌，下限会高一些

1. 这两个线程一直在做 cas，不会暂停，也没有上下文切换。
2. 锁并不都是互斥的，没拿到锁被阻塞的线程，会从 CPU 的 running 队列剥离，有上下文切换。

lock free 不是绝对的好，有它自己的适用场景。lock free 优点是 cost 很小，缺点是竞争激烈时不断重试占用了 CPU。

某些系统实现，轻锁在遇到竞争时，膨胀成重锁。

这是家里有矿，不差钱

外行眼里，写代码就是 crud，做生意无非低买高卖。

@TommyLemon 做到后端不写代码了吗？回顾一下做过的项目，有几个能因此不用写后端代码？就算把范围缩小到 orm 这一层，也没做到完全不写代码。如果前端直接调用，只是把拼 DSL 的工作移交到了前端。如果后端自己去调用这个库，拼 json 真的比拼 sql/hql 简单吗？

你是如何得出受社区欢迎的结论的，star 数吗？我觉得这个指标毫无参考价值。我更关注贡献者数量，和衍生项目或者依赖这个项目的项目指标。

你可以自己搜搜看，结果数量很少，其中不少还是你亲自写的。网友的分享和实践几乎空白，热度跟 star 数量已经没有相关性了。

抛开流行程度或者使用人数不讲，我们只看项目本身。你我最大的分歧在于，你觉得纯 CRUD 接口在后端工作中占有很高比例，但我觉得这个比例很低，绝大多数接口都有业务逻辑夹杂在里面。真正简单的 crud，不仅不用写后端代码，前端代码也不用写，有 django 这类自带 admin 的，也有根据 db 自动生成全套代码的，甚至有外包公司点几下鼠标一个完整项目代码就自动生成了。

@TommyLemon 搜索 name 中包含字母 a
{
"User": {
"name~": "a"
}
}
变为 搜索 sex 为 1
{
"User": {
"sex": 1
}
}

==============================================

难道这里改的不是代码？


10 大痛点我看了，感觉也没那么痛。

1. 带宽，内部系统或者管理后台大多数不需要考虑带宽。需要省带宽时，后端也可以只返回部分字段，甚至换二进制协议。

2. 命名混乱，不同部门或者第三方 API 的命名风格，编码规范解决不了，lint 也解决不了，APIJSON 也解决不了。

3. 数据类型，那是动态类型语言才有的问题，Java 或者 Go 定义好类型，还能变来变去？{}变[]是 php 独有的。

4. 混乱的状态码，跟第 2 点一样，只有很小的项目，不跟别人对接，只用 APIJSON 返回数据才能解决，但是可能吗？

5. 文档跟代码不同步，的确，这个问题比较普遍，也有很多根据代码生成文档的工具，但是往往只能做到字段说明或者参数说明这种程度，不能描述业务逻辑，也没有流程图或者 UML 图。

6. 应用界面和接口强耦合，只要数据依赖不变，UI 随便怎么改都不用后端一起改。接口定义是前后端一起商议的，后端一言堂的情况很多吗？强迫前端用 APIJSON 这种风格的 API 不算拍脑袋？

后面就不多说了，我个人感觉都不是痛点。

如果这 10 大痛点成立，现在应该很多公司在用了，还会写到招聘广告里。

===============================================



请原谅我的抬杠，毕竟你的标题立的太高了

1. 不用写代码
2. 超 Hibernate

假如有 30%符合事实，恐怕早就铺天盖地的用起来了，根本用不着亲自宣传。

swoole 了解一下