- 博客(6)
- 收藏
- 关注
RSS订阅原创 海外技术社区访问方案：+86 手机号登录Tg困境的实测解决记录
登录这一步省下来的时间，够我看好几个技术频道了。有同样需求的可以在评论区自取，希望能帮到遇到同样问题的人。我会把整理内容分享在评论区，也欢迎大家多多交流~附：常见问题速查表格问题建议方案收不到验证码检查运营商是否拦截国际短信，尝试第三方客户端弹出付费验证第三方客户端可绕过，或检查网络环境是否纯净登录后频繁掉线保持 IP 稳定，避免频繁切换节点多设备登录冲突优先使用已登录设备接收应用内验证码基于 2026 年 6 月最新实测信息整理。各平台风控策略持续更新，欢迎补充实战经验。
2026-06-27 09:13:25
181
1
原创 Redis 缓存穿透、击穿、雪崩，我花了 3 年才分清它们的区别
我的踩坑：项目上线时，为了"预热缓存"，一次性加载了 10 万个 key，全部设置了 1 小时过期。解决方案：互斥锁（只有一个线程去查数据库，其他线程等待），或者逻辑过期（不设置 TTL，用逻辑时间判断）。我查了下，很多公司的缓存策略其实是"混着用"的，没有严格区分这三种情况。我的踩坑：早期项目没做校验，有人用脚本批量请求不存在的商品 ID，数据库 CPU 飙到 90%。解决方案：布隆过滤器，或者缓存空值（设置较短的过期时间，比如 5 分钟）。问题：不是查询不存在的数据，是查询存在的数据，但缓存刚好失效。
2026-06-25 11:52:08
177
原创 MySQL 慢查询优化实战：一个订单查询从 8 秒降到 200 毫秒的完整过程
再 EXPLAIN，发现虽然用了 create_time 索引，但 ORDER BY 和 LIMIT 之后，还要回表查 users 和 products 的数据。解决方案：用游标分页，前端传上一页最后一条的 create_time，下一页用 WHERE create_time < '上一页时间' 直接定位。写了个定时任务，把 6 个月前的数据移到 orders_archive 表，原表只保留热数据。但 orders 表字段太多，索引体积太大，不现实。子查询只查 id，走覆盖索引，不回表。
2026-06-17 08:51:53
170
原创 海外即时通讯工具Tg登录异常的技术分析：SMS 验证码链路为何频繁失效
如果用户在前端设置了 60 秒超时重发，实际上第一条短信可能还在路上，用户就触发了第二条请求。目标平台的风控系统会识别高频注册的号码段，直接拒绝向这些号码发送验证码，或者发送后关联账号进入观察名单。部分平台为了用户体验，会在前端显示"已接收"，但实际上并未真正收到短信。当多个维度触发风控阈值时，系统会采取"静默拒绝"策略：前端不报错，但后端不实际发送验证码。这导致一个问题：同样的登录流程，A 用户能成功，B 用户完全不行，而开发者从日志里看不到任何异常，因为请求在运营商侧就被终止了。
2026-06-14 09:58:06
239
3
原创 Spring Boot 3.2 升级踩坑实录：从 2.7 迁移过来，这几个兼容性问题花了我一周
升级不是改个版本号那么简单。Spring Boot 3.2 确实有很多改进（虚拟线程支持、Observability 增强），但迁移成本取决于你的项目"历史包袱"有多重。我的建议是：先在新模块试用，别直接全量升级。如果必须升级，做好一周填坑的心理准备。你们公司升级到 Spring Boot 3 了吗？遇到了哪些坑？我查到的资料大部分只讲新特性，实际迁移的坑很少人写。
2026-06-11 23:38:05
168
2
原创 2026 年还在用 Redis 做缓存？这三个新场景你可能没试过
踩坑点：Stream 的默认消息 ID 是时间戳，如果服务器时钟漂移，可能出现消息乱序。因为 RedisCell 是 C 写的模块，执行是原子性的，不需要自己写 Lua 保证原子性。意思是：用户 123 的配额，15 个初始令牌，每秒补充 30 个，最多存 60 个，这次请求需要 1 个令牌。Redis 做缓存已经是基操了，但最近半年我在生产环境里试了三个"非主流"用法，效果出奇的好。之前用令牌桶算法做 API 限流，代码里自己维护令牌状态，并发高的时候容易有竞态条件。适用边界：能接受近似值的场景。
2026-06-10 09:35:30
251
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人