你有多少用户？这么快担忧到 redis 性能不够用？你没有实际因为 session 频繁写导致性能不够的场景，一切都是凭空想象出来的，那么你的优化也是凭空想象的。

现在 965 太难找了，就算找到了大概率也会逐渐 996 或 995，这就是整个互联网的氛围。

普通人生活就是如此啊，平平淡淡，平平安安。

想要激情是要花钱的，干活那么多年，还不知道钱难赚？

套壳什么的没用，只要资源方看到你的 App 播放了未授权资源一定可以找你麻烦。

参照本站的某被告盗链爱奇艺、优酷的大佬

实际上来说，http code 完成足够使用，但是额外在 json 中定义一个 code 主要是用于前端交互使用。

比如注册接口，App 和 Web 以及大屏的交互逻辑个不一样，不同的错误需要 UI 做不同的交互操作。但是 http code 只有 403，额外定义一个 code 可以在不改后端的情况下，让前端自行处理。

你以为炒股吗？你不想留上海自然不适合入手

你有车吗？是否非轿车类型且拥有四驱系统？

以上条件不能满足的话，建议海鸥岛、大学城走起。

满足以上条件，增城、花都、从化大把水库等着你去露营。

我写过那么多年的代码，没有设计是一步到位的，都是先完成功能代码，再根据功能代码提炼出设计模式。

通用的设计，如接口规范、代码目录架构这个可以参照其他项目或书籍来就行了。但是代码的抽象程度往往没有办法一步到位，就算一步到位在日后的需求上也会逐渐不满足。

遇到过，直接删除输入法，重新添加就好了。

@waibunleung 抛弃第二种，第一种的话跟你直接用 ORM 的对象操作也一样，只不过是分散到 services 里面。

比如
function create(name, age) {
user = new User()
user.setName(name)
user.setAge(age)
user.save()
}

function delete(id) {
user = UserDAO.findById(id)
if (!user) {
return error
}
user.delete()
}


class UserDAO {
function findById(id) {
return UserORM.find('id = %d', id);
}
}

拥有 ORM 只需要封装查询，增、删、改不需要封装到数据访问层里面。

毕竟增、删、改这些业务逻辑比较固定且一般都是面向对象操作。但是查会根据不同的条件查询，这里面变化比较多，所以封装到数据访问层里面方便后期迭代优化。

@kingiis 大专学历就能干掉很多大佬？

多存钱。

买这些位置的房子，等于你月供+房租双倍支出。

INSERT INTO 不支持 where，我以为是 8.0 新特性，但是去查下 8.0 文档并没有支持该语法。

https://dev.mysql.com/doc/refman/8.0/en/insert.html

就是让客户端请求 field 和 expect 来确定要哪些字段和剔除哪些字段

没有社保没得商量

技术部副总监还是算半个管理职？你已经算是中层了，你自己看着办。