做后端开发的时候如何预见问题的发生和解决潜在的问题？

依赖于经验或者看过相关的案例会好答一点，但这有个悖论，如果能提前遇见那大部分情况都能解决；遇到的基本上都是未考虑到或是考虑不完全的的。举个简单例子，比如在做一些排行榜的时候，就必然会有榜单更新的实时性、准确性、稳定性这几个因素的相互考虑。

如果要求实时性高，必然会有缓存；有缓存也必然会影响准确性，怎么及时的更新缓存；如果引入缓存、主动更新机制，系统的复杂度增加，那就又会涉及到监控（这里指的更多是业务层面监控，比如缓存更新失败如何感知），巴拉巴拉……

完全测试， 性能测试， 压测， 完整的监控！ 好多公司不懂微服务。 以为搞个服务就完事了。 但是正因为是微服务。 向上还要考虑服务调用。 服务依赖 ， 完整的服务监控。 等等

别想了，君不见，大厂也是这个崩完那个崩，都是草班台子。

1L 说的很好了，这种事一般就是出一次事长一次记性，如果公司技术氛围跟体量还可以，经常会有一些故障复盘，多听听没坏处

做的多了就知道了，比如做一个带输入输出的接口，后面肯定会遇到 xss 攻击，所以前期一定要做好参数过滤

这种事情就是经验积累的过程。听得多，遇到的多，写东西的时候就能直觉的遇见在什么样的阶段，目前这个方案会产生什么样的问题。

可能性是无穷的
一般都是经验问题吧，也得平衡下系统复杂度

我举个例子：如何设计用户表？
可能会有问题的设计： 所有数据都丢在一张表。很明显随着数据量的增大，这里会成为 Block 系统的点
良好的设计：按照 userId or phone number 进行分库分表，然后数据聚合到 ES 或者其他系统方便进行模糊查询，最后将数据同步到 Hive 中，可以进行大数据分析。（问题：常见的分库分表算法有哪些？如何防止数据倾斜？如何保证数据一致性？如何保证数据安全？如何保证系统平滑的扩容、缩容？）
根据业务的设计：主要访问来自于 C 端还是 B 端。未来是否需要支持单点登录、第三方登录。根据业务的不同，你又可以去做针对性的优化，比如数据库的反范式，多级缓存的设计 。
最后，这只适用于面试。实际情况是：一个系统可能连 1w 个用户都没有，并发也都是个位数。

根据历史经验多想和多测吧，然后出了问题就积累，然后循环

你能预测这些的话，直接买股票，比上班实在

预见问题的发生，应该靠经验吧？
解决潜在的问题，我的理解是只能防御潜在的问题，比如留好日志，能最快分析出问题；比如防御型编程，控制问题的影响范围

只能觉醒见闻色了