yuanxiaosong

@EventListener(ContextRefreshedEvent.class)

home -> home
icloud -> home
microsoft -> home
cn -> home
work -> work
chatgpt -> us
gfw -> proxy
final -> proxy

按照苹果的尿性，应该是周三凌晨发布，中文页面上也写的是 9 月 27 日。

FULL JOIN + RAND()

两年前买了，两年内出现了以下问题：1. 续航打 5 折，2. 右耳经常无法充电，3. 麦克风经常失灵，4. 无法唤醒 siri ，去了售后，耳机和电池仓直接换新了。

你接触过的最大的表是多少行？

我一般不会直接问，会问下面的问题：

你负责的系统上数据量最大的是哪个模块？
该模块有多少用户，每天多少并发，每天产生多少数据，系统运行了多久，总共产生了多少数据，最大的是哪个业务表？
该表上有多少字段，每个字段类型，为什么这么设计，每行数据占用空间多少，整个表占用磁盘空间多少，
有多少个索引，索引占用磁盘空间多少，
再给个查询，能命中哪个索引，type 级别是哪个？
新提个需求，无法命中现有索引，请设计一个新的索引来解决，要求级别必须达到 range ？

结果我这样面试了几次后，领导就换别人当面试官了。

看看我司的分层模型：
filter -> controller -> application -> service -> manager -> dao

filter：统一身份认证，公共参数处理，日志等；
controller：对前端参数验证转换，mq 接收，新旧接口兼容，新旧参数兼容，响应结果按业务裁剪，有些接口 5 年没变过，业务都改了几轮了，调用那些老接口依旧不会报错；
application：采用 ddd 模型后跨领域调用，mq 发送；
service：领域内部业务，一般不互相调用，这里写纯粹的业务，最多就是调用 manager 获取数据或者操作数据，经常都是几百行的；
manager：缓存，领域对象转多个关联表，调用远程服务，切换数据源，比如开始走数据库搜索，后期走 es 搜索，我记得我们最复杂的操作一次要修改接近 50 张表，不在这里的话，service 早疯了；
dao：mysql ，es ，远程调用都在这一层；
企业级开发就这么多层，上了微服务后会按照服务拆分，不要搞形式主义，看看每一层你有没有需求，没有需求可以直接砍掉，还有就是这个和 Spring 没啥关系，纯粹是设计的问题，个人开发就可以一层梭哈就行了。

我的 11pm 首发买的，马上 4 年了，充电次数 1000+，每天不玩游戏，不看视频，要充电两次才能坚持到晚上睡觉，结果电池健康度还有 84%，严重怀疑苹果是有黑科技，唯一的原因是还没过保，打了 400 ，去了店里，都说电池没问题。

试试 remote desktop manager 呢？