我不点 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 了解一下

东北是商业荒漠

@TommyLemon 举个例子，需求从根据身高筛选，改为根据体重筛选，是不是有个地方要把身高改成体重？如果连表的条件改了，能不用改代码吗？

再举个例子，业务状态有变更时发个短信通知，好像还是得写代码。

真正用在 db 层面的 crud 上的开发时间比例很低，大部分还是在处理业务逻辑，而不是简单的数据存取。


我把手上项目挨个遍历了一下，发现没有一个能因此减少工作量，才得到区别不大的结论。

构造查询参数的过程，跟写代码没什么不同，还增加了学习成本。如果业务简单到可以直接丢给前端用，倒是解放了后端，把部分业务代码转移到前端去了。

那多半是 PHP 的锅

冬天靠空调和暖气，户外靠抖

除非偶尔特殊情况，没做完也得按时下班。

ubuntu 的字体渲染是所有发行版中最好的

后端撸前端，也就是个管理后台，当然用 element 了，也不用单页，就当是个自带 mvvm 的大控件库用用也不错，几乎没什么学习成本

一线城市，做六休一，10 到 15k，这哪里是薪资平平，是远低于市场价了

碌碌有为和碌碌无为是不同的，前者是真忙，后者是无能

没有 crud 需求