凌晨一点半接到值班同事的电话说 OA 系统登录不进去了。我第一反应是让他重置密码结果发现流程走到一半卡住了——负责重置密码的管理员当时在外地远程操作权限刚好过期。这种事儿在维护 6 个内部系统的团队里基本每周都要来一回。六个系统六套账号有的强制 90 天改一次密码有的绑定了 AD 域控还有两个外包系统连密码策略都不一样新员工入职光账号开通就要折腾一整天。后来领导拍板必须做统一身份认证一次登录全部系统通行。于是我们选型了一圈最后用 MaxKey 做认证中心把所有 Spring Boot 内部系统接入单点登录。整套方案从部署到 6 个系统全部接入完成前后用了大概三周其中大部分时间不是写代码而是在处理各种联调时的细节。这篇文章就把完整过程和踩过的坑都写出来给同样想用 Spring Boot MaxKey 做单点登录的团队一个参考。1. 六个系统六套密码这次我终于把 SSO 提上了日程1.1 账号体系割裂带来的真实成本我们部门的 6 个内部系统分别是 OA 办公系统、运维工单系统、资产管理系统、项目管理平台、BI 报表平台、内部知识库。这 6 个系统的技术栈还不太一样有的是老式 Struts 改造来的有的是近两年新上的 Spring Boot 项目还有两个是外包团队交付后就没怎么维护过的。但它们有一个共同点各自维护一套独立的用户表。后果就是每个系统都有独立的注册、密码策略、角色权限逻辑。员工入职要分别在 6 个系统里建账号离职要挨个禁用。日常工作中员工在 A 系统改了密码B 系统的密码还是旧的时间一长根本记不清哪个系统用的哪个密码。我们统计过一个月的数据运维组平均每天要处理 7 到 8 次密码重置请求这还没算员工在群里互相问密码的时间。这种账号割裂的问题光靠再招一个管理员解决不了必须从身份认证的源头去统一。1.2 自研认证中心我劝你冷静一开始团队里有人提出自研 SSO 认证中心理由是自己写的最可控。我直接给否了。不是说自研完全不行而是认证这件事的复杂度被严重低估了。单点登录看着简单实际牵扯到 OAuth2 授权码流程、OIDC 用户信息映射、token 签发与校验、跨域会话管理、单点登出、密钥轮换、审计日志等等一堆问题。自己写一套开发周期至少一个半月而且第一版基本只能覆盖最简单的场景后面每个系统接入都要给自定义协议填坑。我当时给领导算了一笔账自研方案的人力成本、维护成本、安全风险加起来远高于直接采用成熟的认证基础设施。内部系统最需要的不是全世界独一无二的登录协议而是稳定、通用、社区活跃的认证方案。1.3 MaxKey 为什么适合内部系统我们最后选了开源项目 MaxKey原因很直接第一它支持 OAuth2.0、OIDC、CAS、SAML 这些主流协议不需要为每一个系统定制接入协议。老系统如果只支持 CAS直接配 CAS 模式新系统统一走 OIDC非常灵活。第二MaxKey 本身就是 Java 技术栈跟 Spring Boot 生态天然契合。问题排查时可以直接看源码也可以基于它的插件机制做二次开发。第三部署架构清晰。MaxKey 提供标准安装包和独立部署方式认证服务、管理控制台、数据库分离适合企业内部部署。当然MaxKey 也不是没有学习成本。它的管理端菜单逻辑和配置项较多第一次接触的人容易被庞大的配置界面吓到。但只要你理解了 OIDC 的整体流程再回头去看那些配置项基本上就是一一对应的事。2. MaxKey 部署与协议基础先把 OIDC 流程吃透再写代码2.1 部署 MaxKey 的两种方式我们当时在部署方式上纠结了一下最终选择了独立部署。MaxKey 官方提供了两种主要方式一种是 Docker 编排方式适合快速验证。把maxkey镜像跑起来映射 443 端口初始化数据库就可以在浏览器里打开管理端页面了。这种方式最大的好处是省事适合先搭一套 demo 环境跑通流程。另一种是标准安装包部署适合生产环境。解压、配置数据库连接、部署到 Tomcat 或 Jetty、配置 HTTPS 证书步骤多一点但更可控。我们生产环境用的是这种因为内部系统对安全要求不低需要自己管理证书和数据库。这里要特别提醒一句MaxKey 的 HTTPS 配置一定要在一开始就搞定。OIDC 协议要求回调地址必须是 HTTPS如果你用 HTTP 做联调后面换 HTTPS 的时候回调地址全部要改一遍非常麻烦。我们第一个系统接入时偷懒用了 HTTP后来统一上 HTTPS所有应用的 redirect_uri 挨个重改来回折腾了一天。2.2 OIDC 授权码模式到底是怎么流转的说到 OIDC很多刚接触 Spring Boot 的人会把它理解成一个登录按钮跳转过去再跳回来这样说没错但真正的流程远比这个复杂。你要写对配置至少得理解下面这 7 步用户访问业务系统发现未登录Spring Security 将浏览器重定向到 MaxKey 的 authorization 端点。MaxKey 检查自身的会话状态如果用户没有在 MaxKey 登录过则展示登录页。用户输入账号密码MaxKey 验证通过后生成临时授权码authorization code通过浏览器 302 重定向回业务系统的回调地址并把 code 附加在 URL 上。业务系统后端拿着 code通过 POST 请求去 MaxKey 的 token 端点换取 token。这一步发生在服务器端不经过浏览器。MaxKey 返回 id_token、access_token 和 refresh_token。业务系统拿到 id_token 后可以从中解析出用户身份信息也可以调用 userinfo 端点获取更多属性。业务系统根据用户信息建立本地会话比如生成自己的 session后续请求就不需要再走 MaxKey 了。理解这个流程后很多配置项就变得顺理成章了。authorization-uri、token-uri、user-info-uri、redirect-uri 这些地址本质上就是对上述每一步的端点定义。2.3 在 MaxKey 管理端注册应用的几个关键字段在 MaxKey 管理后台新建应用时有几个字段决定成败第一个是回调地址redirect_uri。这个地址必须和 Spring Boot 应用里实际使用的回调地址完全一致不然 MaxKey 会直接拒绝授权请求。Spring Boot 的 oauth2Login 默认回调地址是{baseUrl}/login/oauth2/code/{registrationId}所以注册应用时回调地址就要填https://你的域名/login/oauth2/code/maxkey。第二个是授权类型也就是 grant type。我们用的是authorization_code这是 OIDC 最标准、最安全的授权方式适用于有后端服务的应用。第三个是scope。OIDC 至少需要openid此外profile和email按需申请。scope 决定了你能拿到哪些用户信息比如profile里包含用户名、昵称、头像等email里包含邮箱地址。第四个是应用类型。MaxKey 会根据应用类型提供不同的配置模板Spring Boot 这类后端渲染应用选择Web 应用即可。我在早期接入时犯过一个低级错误把回调地址填成了http://localhost:8080/login/oauth2/code/maxkey用于本地测试结果上生产环境后所有人登录都报 redirect_uri 错误。这个教训后面我会专门展开讲。3. 三种接入方式对比我给 Spring Boot 团队选了最适合的那条路3.1 嵌入式单点登录的三种实现路径在搜单点登录相关资料时大家会看到内嵌单点登录三种实现方式这种说法。实际上Spring Boot 应用接入 MaxKey 这类 OIDC 认证中心主流的实现路径确实可以归纳为三种第一种是基于 Spring Security 的 oauth2Login 配置。这是 Spring Boot 官方支持的方式依赖spring-boot-starter-oauth2-client通过配置application.yml和少量 Java 配置类就能把整个 OIDC 登录流程交给框架处理。适合绝大多数基于 Spring Boot 正规开发的项目。第二种是使用 MaxKey 提供的客户端 SDK 或直接调 HTTP API。这种方式适合那些没有使用 Spring Security 的老项目或者是不想引入 Spring Security 复杂概念的场景。你需要在代码里自己封装授权 URL 跳转、回调处理、token 管理逻辑。灵活度高但代码量也大还要自己处理各种异常场景。第三种是自定义 Filter 实现完整 OIDC 流程。这种方式适合那些对登录流程有特殊定制需求的场景比如要对接多个认证源、要自定义 token 格式、要绕过 Spring Security 的某些行为。工作量最大但完全可控。三者的取舍逻辑其实很清晰。新开发的 Spring Boot 项目直接用第一种方案这是性价比最高的路径老系统改造但技术栈还是 Java可以走第二种如果系统本身就有复杂的认证逻辑且团队对 Spring Security 非常熟第三种也可以考虑。我们这次 6 个系统里有 4 个是比较规范的 Spring Boot 项目直接走第一种方案。剩下两个老系统一个是市面上买的商业软件改不动代码通过 MaxKey 的泛 OAuth2 协议接入另一个是外包项目用的是单机 session 认证模式我们改成第二种方案用 MaxKey 的统一登录 API 做了一把对接。3.2 为什么我最终推荐 Spring Security OAuth2 客户端如果让我给同样情况的团队一个标准答案我会说新系统一律用 Spring Security 的 oauth2Login 接入 MaxKey不要自己造轮子。原因很简单Spring Boot 框架已经把 OAuth2 客户端的功能做得很完整了。授权码跳转、token 刷新、用户信息封装、跨站请求伪造防护、session 管理、登出处理这些全部内置。你要做的只是配置 少量定制。我之前见过不少人在 Spring Boot 里手写 OAuth2 客户端其实大部分是因为不了解 Spring Security 已经提供了这个能力。结果代码写了几百行最后还没有框架处理得好安全边界也容易漏。3.3 多系统共享登录态的思路接入方案定了之后还有一个问题要想清楚6 个系统都有自己的本地 session用户从 A 系统跳到 B 系统时怎么保证不用重新登录这里要理解一个关键点OIDC 单点登录的登录态分为两层。一层是浏览器里 MaxKey 域下的认证中心会话另一层是各个业务系统自己的本地会话。用户第一次访问 A 系统未登录重定向到 MaxKey 登录成功后MaxKey 域下就有了一个会话 Cookie。之后用户访问 B 系统时业务系统把用户引导到 MaxKeyMaxKey 发现浏览器里已经有会话就不再要求输入密码直接颁发一个新的授权码让 B 系统完成本地登录。这就是一次登录、全系统通行的底层逻辑。所以业务系统之间并不需要共享 session只需要确保受保护资源要么返回未登录状态、要么自动重定向到 MaxKey而 MaxKey 的会话是正确的。因此部署 MaxKey 时建议单独用一个认证域名同时业务系统回调也统一走 HTTPS 域名避免跨域 Cookie 带来的 反复登录 问题。4. 从配置到代码Spring Boot 接入 MaxKey 的完整改造过程4.1 引入依赖与 application.yml 核心配置接入的第一步是引入依赖。在 Spring Boot 项目的pom.xml中加入dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-oauth2-client/artifactId /dependency注意不必单独引入spring-boot-starter-securityoauth2-client会自动带上来。如果是 Spring Boot 2.x 项目确保版本是 2.4 以上因为低版本的WebSecurityConfigurerAdapter配置方式在新版本里被废弃了。我们现在普遍用的是 Spring Boot 2.7 或 3.x安全配置写法已经全面转向组件化风格。然后配置application.ymlspring: application: name: oa-system-springboot security: oauth2: client: registration: maxkey: provider: maxkey client-id: your-client-id client-secret: your-client-secret authorization-grant-type: authorization_code redirect-uri: {baseUrl}/login/oauth2/code/{registrationId} scope: - openid - profile - email provider: maxkey: issuer-uri: https://sso.example.com/maxkey这里issuer-uri是 MaxKey 的 OIDC 服务发现地址。MaxKey 实现了 OIDC 的 discovery 文档Spring Boot 会根据这个地址自动去拉取 authorization、token、userinfo 等端点信息。如果你用的是测试环境建议把这串地址先确认一下最直接的方法是浏览器访问https://sso.example.com/maxkey/.well-known/openid-configuration能返回 JSON 说明地址是对的。4.2 编写安全配置类接下来是安全配置。这一步要明确哪些资源是公开的、哪些受保护以及登录成功后跳转到哪里。Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf.disable()) // 内部系统可自行评估必要时开启 .authorizeHttpRequests(auth - auth .requestMatchers(/public/**, /login, /error).permitAll() .anyRequest().authenticated() ) .oauth2Login(oauth2 - oauth2 .loginPage(/login) // 自定义登录页入口 .defaultSuccessUrl(/portal, true) .failureUrl(/login?errortrue) ) .logout(logout - logout .logoutSuccessUrl(/) .invalidateHttpSession(true) .deleteCookies(JSESSIONID) ); return http.build(); } }这里defaultSuccessUrl(/portal, true)表示成功登录后固定跳转到/portal如果改成falseSpring Security 会优先跳转到用户最初访问的受保护页面。这个细节容易忽略你可以根据实际体验决定。另外如果你不想展示默认的 Spring Security 登录页可以配置loginPage指向一个自定义 URL。但内部系统一般直接让未认证用户跳到 MaxKey 登录即可默认的oauth2Login行为就是在未登录访问受保护资源时自动重定向到 MaxKey自定义登录页反而不常用。4.3 用户信息映射把 MaxKey 用户对接到本地用户体系拿到 MaxKey 返回的用户信息后还需要把它和本地用户体系关联。比如 OA 系统可能要判断该用户是管理员还是普通员工BI 平台可能要按用户部门做行级数据权限。默认情况下Spring Security 会从 id_token 和 userinfo 端点获取用户属性。如果你只需要用户名和邮箱什么都不用做直接从OidcUser里取就行。但现实是很多内部系统的用户表和 MaxKey 的用户属性并不完全一致。我们当时遇到的情况是MaxKey 里的用户名是员工工号但 BI 报表平台的历史用户表里存的是中文姓名加手机号。我写了这样一个自定义的 OIDC UserServiceService public class MaxKeyOidcUserService extends DefaultOidcUserService { Autowired private LocalUserRepository localUserRepository; Override public OidcUser loadUser(OidcUserRequest userRequest) throws OAuth2AuthenticationException { OidcUser oidcUser super.loadUser(userRequest); String username oidcUser.getPreferredUsername(); LocalUser localUser localUserRepository.findByEmployeeNo(username); if (localUser null) { // 新用户未在本地系统建立映射这里按策略决定是自动创建还是拒绝 throw new OAuth2AuthenticationException(new OAuth2Error(user_not_found), 用户尚未在本地系统中开通账号); } // 把本地系统的角色和权限放入 authorities ListGrantedAuthority authorities localUser.getRoles().stream() .map(role - new SimpleGrantedAuthority(role.getCode())) .collect(Collectors.toList()); return new DefaultOidcUser(authorities, oidcUser.getIdToken(), oidcUser.getUserInfo()); } }然后在安全配置里挂上这个 service.oauth2Login(oauth2 - oauth2 .userInfoEndpoint(userInfo - userInfo .oidcUserService(maxKeyOidcUserService) ) )这样登录成功后当前用户就带上了本地系统的角色与权限业务代码可以直接通过SecurityContextHolder获取非常方便。4.4 登录成功后把用户信息交给前端单点登录改造不只是后端的事前端也要知道当前登录用户是谁。我们在统一登录成功后增加了一个/portal页面这个页面会调一个接口获取当前用户信息用于展示欢迎 XXX和各个系统的入口链接。RestController public class UserController { GetMapping(/portal/userinfo) public MapString, Object userInfo(Authentication authentication) { OidcUser oidcUser (OidcUser) authentication.getPrincipal(); // 只返回前端需要的字段避免暴露 token 等敏感信息 return Map.of( username, oidcUser.getPreferredUsername(), displayName, oidcUser.getFullName(), email, oidcUser.getEmail() ); } }这里有一个经验不要在接口里把完整的OidcUser对象直接序列化返回给前端因为里面包含 id_token、access_token 和各类声明泄露出去会有安全隐患。只返回前端展示、业务判断需要的字段就够了。5. 6 个系统联调踩坑实录与排查链路5.1 redirect_uri 矛盾本地测试与生产环境域名不一致第一个坑几乎所有接入方都会踩。我在 MaxKey 管理端创建应用时回调地址填的是测试服务器的地址比如https://test-oa.example.com/login/oauth2/code/maxkey。本地开发时拿了一张本地回调地址的配置结果本地一登录MaxKey 直接报redirect_uri 参数错误。排查过程其实不复杂但要养成固定思路第一步先确认 MaxKey 管理端注册的回调地址是否和 Spring Boot 实际发送的 redirect_uri 完全一致注意协议、域名、端口、路径任何一个字符都不能差。第二步查看浏览器地址栏里跳转到 MaxKey 时的完整 URL。授权请求的 URL 上有一个redirect_uri参数把它复制下来和 MaxKey 管理端配置对比。第三步确认 Spring Boot 的redirect-uri配置。我们用的默认配置{baseUrl}/login/oauth2/code/{registrationId}baseUrl会自动解析成当前请求的主机和端口。如果你在开发机上改了很多个域名很可能解析出来的域名和你预期的并不一样。最终解决办法是在 MaxKey 管理端配置多个回调地址每套环境注册一个应用或者利用 MaxKey 允许配置多个回调地址的功能把本地、测试、生产三个地址都加进去。Spring Boot 端不要写死 redirect-uri直接使用默认占位符让框架自动生成。5.2 Nginx 反向代理导致回调地址少了 HTTPS第二个坑更隐蔽。所有流量经过 Nginx 反向代理到达 Spring Boot 应用时Spring Boot 自身看到的是来自 Nginx 内部的 HTTP 请求而不是客户端访问的 HTTPS 请求。这时候框架生成的baseUrl会变成http://内网地址:8080回调地址就变成了http://...和 MaxKey 里注册的https://...不一致照样报错。这个问题有两个解决方向一是 Nginx 侧正确传递转发头。在 Nginx 配置里加上proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $remote_addr;二是 Spring Boot 侧开启转发头处理。在application.yml里配置server: forward-headers-strategy: framework用了这个配置后Spring Security 会把X-Forwarded-Proto带过来的https://信息当作实际请求协议生成的回调地址就正确了。排查这个问题的链路是查看 MaxKey 报错信息发现 redirect_uri 是http://开头然后看 Spring Boot 日志发现OAuth2AuthorizationRequestRedirectFilter里生成的 redirectUri 不对再对比 Nginx 请求头发现缺少X-Forwarded-Proto。三步定位。5.3 用户信息属性映射不上第三个坑是 MaxKey 返回的用户属性和各系统的用户表字段对不上。比如 MaxKey 里叫preferred_username的字段在知识库系统里对应的字段是empNo在资产管理系统里又是loginName。如果你不做映射默认情况下DefaultOidcUserService拿到的属性可能不是你要的那个。当时我们通过oidcUser.getClaimAsString(employee_no)去取工号结果返回 null原因是 MaxKey 管理端的属性映射里没有把 employee_no 配置到 id_token 中。解决方式是在 MaxKey 管理端修改应用的用户属性范围或者在 Spring Boot 侧通过 userinfo 端点获取完整属性列表。我建议先写一个小接口GetMapping(/debug/oidc-attrs) public MapString, Object debugAttrs(Authentication authentication) { if (authentication.getPrincipal() instanceof OidcUser oidcUser) { return oidcUser.getClaims(); } return Map.of(); }临时加这个接口登录后把所有 claim 打出来看一眼 MaxKey 实际返回了哪些字段再决定映射关系怎么写了。定位问题之后立刻删掉这个接口避免成为安全隐患。5.4 跨系统访问时偶发出现再次登录还有一个让测试同事很困惑的问题明明刚在 A 系统登录过第一次点进 B 系统却还要重新输密码但第二次点就正常了。排查后发现这其实是 MaxKey 域下的 Cookie 会话有效期太短导致的。因为默认的 MaxKey 会话超时时间配置成 30 分钟用户上一次访问 MaxKey 之后超过 30 分钟再进入新系统MaxKey 自身的会话已经过期了自然要重新登录。这里要注意业务系统本地的 session 和 MaxKey 的 session 是两套超时策略。用户长时间停留在 A 系统不跳转A 系统的本地 session 可能还有效但 MaxKey 的会话已经过期。等用户第一次跳到 B 系统时MaxKey 发现会话过期要求重新登录。如果你希望一次登录一天内都不需要再输密码可以在 MaxKey 管理端把会话超时时间调长一些。但要注意这个设置会直接影响安全策略内部系统可以放宽对外系统不建议这么做。我们当时把 MaxKey 的会话策略设置成 8 小时自动过期同时各业务系统的本地 session 也设置成相应的 8 小时保证了整体体验一致。6. 单点登出、安全加固与后续运维经验6.1 单点登出的配置思路单点登录做了单点登出同样不能落下。用户点了某个系统里的退出登录理论上应该同时把 MaxKey 的会话和所有业务系统的会话都清掉。Spring Boot 侧的登出配置很简单但关键在于要调用 MaxKey 的登出端点。OIDC 规范里的登出方式有几种我们采用的是logout配置 跳转到 MaxKey 登出 URLspring: security: oauth2: client: registration: maxkey: # ... logout-uri: https://sso.example.com/maxkey/logout实际在代码里我写了一个登出接口先清理本地 session再重定向到 MaxKey 登出地址GetMapping(/logout) public String logout(HttpServletRequest request, HttpServletResponse response) { SecurityContextHolder.clearContext(); request.getSession().invalidate(); return redirect:https://sso.example.com/maxkey/logout; }MaxKey 收到登出请求后会清除它自己域下的会话。这样用户下一次访问任何系统都会被要求重新登录。这里有个细节当你从 A 系统发起登出跳转到 MaxKey 登出后浏览器再回到 A 系统是未登录状态但 B 系统呢用户如果手动输入 B 系统的地址理论上 B 系统会检查本地 session。因为业务系统的 session 是各自独立的登出 A 系统并不会清除 B 系统的本地 session所以用户可能直接用浏览器返回键又进入了 B 系统看起来像登出没生效。要真正实现全系统登出要么通过 MaxKey 支持后台主动踢人要么在各系统之间通过消息通知清除会话。我们内部系统因为安全要求没那么极限只实现了登录中心的登出 各业务系统本地 session 清除整体体验已经能接受。6.2 client-secret、签名算法与证书管理安全配置这块我单独提几个容易被忽视的点。第一client-secret 不要明文写在 application.yml 里。内部系统有时安全意识比较松散但生产环境的配置文件一旦泄露攻击者就可以冒充应用和认证中心交互。建议使用 Spring Boot 的配置加密方案或者把密钥放到环境变量、配置中心里。我们后来统一放到了配置中心并在部署流水线里做了密钥注入。第二授信算法要确认。MaxKey 默认支持的 JWT 签名算法和 Spring Boot 默认能解析的算法可能不一致如果发现 id_token 解析报签名错误先检查两边的签名算法配置。一般建议使用 RS256对称密钥的 HS256 在分布式环境下维护成本高。第三证书有效期要留足。如果说证书过期整个认证中心直接不可用所有系统全部无法登录。我在一个内部项目上经历过证书过期导致的线上事故从那以后养成了证书到期前 30 天加监控告警的习惯。6.3 从第 1 个系统到第 6 个系统的推进做法最后说说推进过程。6 个系统一次性同时接入风险太大我们不建议这么做。我当时的推进节奏是分了三批第一批先接入 OA 系统和 BI 报表平台。这两个系统的开发团队是我们组内自己人改动起来最快而且它们的使用频率高能快速验证体验。第二批接入运维工单系统和资产管理系统。这两个系统有一定历史包袱但还算有代码权限主要工作是适配用户字段映射。第三批接入项目管理平台和内部知识库。项目管理平台是商业软件只能走标准 OIDC 对接知识库是外包项目我们直接和外包团队交接了配置说明让其配合改造。每接入完一个系统我们都会做一轮验证新员工入职是否能直接一次登录、离职后账号禁用是否立即生效、密码修改后是否所有系统同步生效。这三点是内部系统单点登录最直接的价值度量。关于上线观察指标我建议大家关注三个数字登录失败率、单点登录平均跳转耗时、密码重置工单量。我们上线两个月后密码重置工单量下降了 90% 以上新员工系统开通时间从 1 天缩短到 10 分钟这个效果拿来和领导汇报非常直观。最后再说一个我个人的习惯接入过程中我发现一个特别有用的做法就是每接入完一个系统都把 MaxKey 管理端的应用配置截图和 Spring Boot 的 yml 配置存档一份。6 个系统接完之后这些文档成了排查问题的一手资料。很多登录异常问题比如回调地址不一致、用户属性丢失直接在存档里对比一下就能定位不用每次重新翻管理后台。另外如果你也是第一次接触 MaxKey建议先在本地用 Docker 起一套环境用最小配置跑通一个最简单的 Spring Boot demo再开始正式接入。我第一次直接用生产环境摸索结果配置改来改去把管理端的一些默认设置也动了后面排查起来很被动。先用 demo 环境把协议流程走一遍再上生产能少走很多弯路。
