从SSO单点登录开发中得到的通用反思
这次SSO功能的开发，折腾了不少时间，也踩了不少坑。回头看看，虽然具体问题是OAuth2对接、证书配置、K8s部署这些技术细节，但里面暴露出的问题，其实在很多项目里都会遇到。我把这些体会梳理一下，希望能对以后有点用。
一、真正的问题不是技术新，而是反馈太慢
我做这个项目，就是冲着里面有不熟的东西来的——OAuth2协议、Nginx反向代理、K8s、Python异步……如果全是干过的活，那就没意思了，要么早转管理了，要么就是重复劳动。所以“技术不熟“、”技术基础薄弱”从来不是问题，问题是怎么在多个陌生领域同时涌入时，能快速上手。
这次最大的痛，是试错反馈周期太长。本地连不上真实的SSO服务器，每次改完代码，都要提交、构建、部署、测试，一圈下来半个多小时。本来试错是学习的必经之路，但这条路太长了，走几步就累得慌。如果能打通网络，让本地直接调测试环境，或者多做些单元测试、模拟测试，很多问题早就能发现，不用等到部署后才报错。
二、几个具体的教训
-
接口文档：对方SSO不是标准OAuth2实现，但文档里没标出来，搞得我先按标准调用，问题一堆。后来发现，对接陌生API时，第一件事应该是拿个最小脚本把每个接口的真实行为摸一遍，把差异记下来，别信文档说的“兼容标准”。
-
环境配置：SSL证书、K8s ConfigMap、Ingress……这些环境相关的东西反复改，每次出错都得折腾半天。后来想，要是一开始就模板化、版本化，再加个启动前配置检查，能省不少时间。
-
AI辅助：这次用了不少AI生成代码，快是快，但是构建AI开发流程本身也是很大工作量。
三、三遍法则：解决问题的通用套路
回想整个过程，我发现自己解决问题其实有个隐含的节奏，叫“三遍法则”：
第一遍：快速跑通，发现问题。
这时候方案很糙，目标就是让功能“能跑”，看看哪里有坑。这一遍检验的是项目本身——需求清不清楚，技术难点在哪。
第二遍：真实环境验证，暴露认知缺陷。
把第一遍的方案放到真实环境里跑，隐藏的问题全出来了。但更重要的是，这些问题往往反映了我自己的认知错误——比如我以为OAuth2 token该放Header，结果人家要放Query；我以为证书配好了，结果路径写错了。这一遍检验的不只是方案，更是我的认知。失败不是坏事，它让我看到自己哪些地方想错了、理解偏了，逼着我修正思维方式。
第三遍：优化沉淀，变成可复用的东西。
问题都解决了，方案稳定了，这时候要把经验记下来——写成文档、抽成模板、总结成问题库。这一遍检验的是能不能把经验变成资产，下次不用再踩一遍。
这三遍缺一不可。第一遍是“知道有什么问题”，第二遍是“知道自己不知道什么”，第三遍是“把知道的东西留下来”。
四、下愚之人的智慧
最后想说说心态。做技术的人，总希望自己能一眼看穿所有问题，提前避开所有坑。但现实是，没人能做到。特别是面对新东西，我们就是在黑暗里摸索，撞墙，然后找路。
“下愚之人，并不能远远的察觉问题并避开，能在遇到问题后，直面问题，解决问题，就挺好了。”
真正的本事不是“预见”，而是“应对”。每次遇到问题，能硬着头皮去查日志、改代码、问人，最后把它搞定，这就是成长。而如果能更进一步，在解决问题后反思一下：我为什么之前想错了？我的认知哪里有问题？那这次失败就值了。
所以以后做项目，我不会再因为自己没提前看到坑而自责，那是神的标准。我只要做到：遇到问题，解决问题，然后沉淀下来，就够了。
