根据QQ号做灰度发布命中7:2:1 ​

• 取QQ号最后一位作为标准， 0-6为第一类，7-8为第二类，9为第三类
• 通过哈希算法确保均匀分布， qqNumber.hashCode() % 10; // 取模10（0-9）
• 给每个QQ号生成一个值，这个值的生成分布为7:2:1
• 实现方式：后端接口接收QQ号，计算hashCode后取模，根据结果分配到不同灰度组，保证流量按7:2:1分布，便于灰度发布和风险控制。

项目难点 ​

• 如何保证哈希分布的均匀性，避免某一组用户过多或过少。
• 灰度发布过程中，如何快速回滚和监控异常。
• 多端（Web/小程序/APP）一致性处理，防止用户切换端后体验不一致。
• 需要兼容历史数据和新用户的分组逻辑。

项目优化，具体量化效率多少 ​

• 优化前：全量发布，出现问题影响所有用户，回滚慢。
• 优化后：灰度分组，问题影响面缩小到10%-20%，回滚和定位更快。
• 通过分组发布，线上故障率降低80%，回滚时间缩短50%。
• 系统监控和报警响应速度提升30%。

优点和缺点 ​

• 优点：风险可控，问题影响面小，便于A/B测试和新功能试点。
• 缺点：分组逻辑复杂，需保证分组一致性，测试覆盖面需更广。
• 需要额外的监控和分组管理成本。

C端经验有哪些 ​

• 用户体验优先，灰度发布需保证用户无感知。
• 需做好异常兜底和回滚机制，避免用户遇到不可用页面。
• 多端同步，防止用户在不同端体验不一致。

做小程序收获到什么 ​

高并发相关的处理

• 学会了小程序端的缓存和异步请求优化，减少接口压力。
• 通过分布式限流和降级，保障高并发下服务稳定。
• 利用CDN和静态资源缓存，提升页面加载速度。
• 监控小程序端的性能瓶颈，及时优化慢接口。

产品经理在开发即将完成阶段，临时改需求 ​

• 需与产品经理及时沟通，评估改动影响。
• 优先保证核心功能上线，非核心需求可排期后续迭代。
• 记录需求变更，做好版本管理和回滚预案。

后端非要把接口拆成好几个 ​

• 拆分接口有利于单一职责、易于维护和扩展。
• 但需注意接口间的依赖和调用链路，避免过度拆分导致性能下降。
• 前后端需协商好接口规范，保证数据一致性和调用效率。