企业官网建设流程全解析

1. 问题现场：一个典型的跨域错误是如何发生的

最近在对接钉钉企业内部应用时，遇到了一个看似简单却让人头疼的问题。场景是这样的：我们开发了一个H5应用，需要调用钉钉的开放平台API来获取企业内部应用的access_token。前端页面部署在https://myapp.com，而调用钉钉API的请求发往https://api.dingtalk.com。当我在浏览器控制台执行这段看似标准的fetch或XMLHttpRequest请求时，熟悉的红色错误出现了：

Access to XMLHttpRequest at ‘https://api.dingtalk.com/v1.0/oauth2/accessToken’ from origin ‘https://myapp.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Headers’ header is present on the requested resource.

这个错误信息对于前端开发者来说再熟悉不过了——跨域资源共享（CORS）问题。但这里有个关键点：错误明确指出问题出在Access-Control-Allow-Headers这个响应头上。这意味着，浏览器发送的预检请求（Preflight Request）中携带了一些自定义或非简单请求头，而钉钉的API服务器在响应预检请求时，没有在Access-Control-Allow-Headers中明确允许这些头，导致浏览器判定请求不安全，从而阻止了后续的实际请求。

这个问题的核心在于，钉钉的开放平台API在设计上主要服务于服务端对服务端的调用，其接口本身并未为浏览器环境下的直接跨域调用做CORS配置。因此，当你试图从前端JavaScript直接调用https://api.dingtalk.com/v1.0/oauth2/accessToken这个接口时，浏览器出于安全策略的拦截是必然结果。理解这一点，是解决所有后续问题的起点。

2. 为什么前端不能直接调用获取access_token的接口

要彻底解决这个问题，我们必须先理解为什么钉钉（以及绝大多数类似平台）不推荐甚至“禁止”前端直接调用获取access_token的接口。这背后涉及到几个关键的安全和架构原则。

首先，access_token是调用钉钉API的钥匙，它代表了应用的身份和权限。获取access_token需要用到应用的AppKey和AppSecret，这组凭证是应用的最高机密。如果将这些凭证硬编码在前端JavaScript代码中，无异于将家门钥匙挂在门口。任何用户只要打开浏览器开发者工具，查看网络请求或源代码，都能轻易地窃取这组密钥。攻击者拿到密钥后，可以以你的应用名义任意调用钉钉API，窃取企业数据、发送恶意消息，造成严重的安全事故。

其次，从技术架构上看，钉钉的OAuth 2.0客户端凭证模式（Client Credentials Grant）——也就是用AppKey和AppSecret换Token的模式——本身就是为可信的后端服务器间通信设计的。这种模式假设客户端（即你的服务器）是保密的、受控的环境。浏览器是一个完全公开、不受控的环境，根本不符合“保密客户端”的前提条件。

最后，CORS策略是浏览器实施的安全机制，服务端可以控制是否允许跨域。钉钉API服务端没有为oauth2/accessToken这类敏感接口配置CORS头（如Access-Control-Allow-Origin: *），这本身就是一种明确的安全设计：主动阻止来自浏览器端的直接调用，强制开发者走更安全的服务端中转路径。所以，那个关于Access-Control-Allow-Headers的错误，其实是这个深层安全策略在前端表现出的一个技术症状。

3. 正确的架构：服务端代理模式详解

既然前端不能直接调用，那正确的做法是什么？答案是：服务端代理模式。这是解决此类问题的标准且安全的架构。其核心思想是，在前端（浏览器）和你最终要调用的第三方API（钉钉）之间，插入一个你自己可控的后端服务作为中间层。

整个流程可以分解为以下几个清晰步骤：

1. 前端发起请求：你的H5页面（运行在用户浏览器中）需要获取钉钉数据时，不再直接请求api.dingtalk.com，而是请求你自己服务器的某个安全接口，例如https://api.myapp.com/dingtalk/token。
2. 服务端处理鉴权：你的后端服务（如用Node.js、Java Spring Boot、Python Flask等编写）收到前端的请求。在这个安全的服务器环境中，你可以安全地存储和使用钉钉应用的AppKey和AppSecret。后端服务使用这组密钥，向钉钉的https://api.dingtalk.com/v1.0/oauth2/accessToken接口发起服务器到服务器的HTTPS请求。
3. 服务端获取并缓存Token：钉钉API验证密钥后，将access_token返回给你的后端服务。这里有一个非常重要的优化点：access_token通常有7200秒（2小时）的有效期。你的后端服务不应该每次前端请求都去钉钉获取一个新的Token，而应该实现一个缓存机制（如Redis、内存缓存），在Token有效期内重复使用它。这不仅能提升性能，还能避免触发钉钉的接口调用频率限制。
4. 服务端响应前端：你的后端服务将获取到的access_token（或者直接用这个Token帮你调用完钉钉业务API后得到的数据）返回给前端浏览器。
5. 前端接收数据：前端收到来自自己服务器的响应，顺利完成数据获取。由于这个请求是前端到api.myapp.com，属于同源或你已正确配置CORS的域名，因此不会触发跨域错误。

这个模式完美规避了所有风险：敏感信息不出服务器、符合OAuth2.0的安全假设、由你自己的服务端控制CORS策略。接下来，我们就以最常见的Node.js（Express）和Spring Boot为例，看看如何具体实现这个代理层。

4. 实战：构建Node.js（Express）代理服务

我们首先用Node.js和Express框架来快速构建一个安全、高效的代理服务。选择Node.js是因为它对前端开发者非常友好，且适合处理高并发的I/O密集型任务（如API代理）。

4.1 项目初始化与依赖安装

创建一个新的项目目录，初始化并安装必要的依赖。

mkdir dingtalk-proxy-server cd dingtalk-proxy-server npm init -y npm install express axios cors dotenv

• express: Web框架，用于创建HTTP服务器和路由。
• axios: 优秀的HTTP客户端库，用于向后端（钉钉API）发起请求。比内置的http模块更易用，支持Promise。
• cors: Express中间件，用于方便地为你自己的代理接口配置CORS策略，允许你的前端域名访问。
• dotenv: 用于从.env文件加载环境变量，避免将敏感信息（如AppSecret）硬编码在代码中。

同时，我们安装nodemon作为开发依赖，用于开发时热重载。

npm install --save-dev nodemon

在package.json中添加启动脚本：

{ "scripts": { "start": "node server.js", "dev": "nodemon server.js" } }

4.2 核心代理接口实现

创建server.js作为服务入口文件，并建立核心的获取Token的代理接口。

// server.js require('dotenv').config(); // 加载环境变量 const express = require('express'); const axios = require('axios'); const cors = require('cors'); const app = express(); const PORT = process.env.PORT || 3000; // 使用cors中间件，配置允许来自你前端域的请求 // 在生产环境中，应将origin设置为你的前端实际域名，如 ['https://myapp.com'] app.use(cors({ origin: process.env.FRONTEND_ORIGIN || 'http://localhost:8080' })); app.use(express.json()); // 解析JSON格式的请求体 // 内存中的简单缓存对象，生产环境应使用Redis const tokenCache = { value: null, expireTime: 0, }; /** * 获取钉钉access_token的代理接口 * 安全要点：此接口不应直接暴露AppSecret，所有鉴权逻辑在服务端完成。 */ app.get('/api/dingtalk/token', async (req, res) => { try { const now = Date.now(); // 检查缓存中是否有未过期的token if (tokenCache.value && tokenCache.expireTime > now) { console.log('返回缓存的token'); return res.json({ success: true, access_token: tokenCache.value, fromCache: true, }); } // 缓存无效，向钉钉请求新token // 注意：AppKey和AppSecret从环境变量读取，绝不写死在代码里！ const appKey = process.env.DINGTALK_APP_KEY; const appSecret = process.env.DINGTALK_APP_SECRET; if (!appKey || !appSecret) { return res.status(500).json({ success: false, error: '服务器配置错误：未找到钉钉应用凭证。', }); } const dingtalkResponse = await axios.post('https://api.dingtalk.com/v1.0/oauth2/accessToken', { appKey, appSecret, }, { headers: { 'Content-Type': 'application/json', }, }); const { accessToken, expireIn } = dingtalkResponse.data; // 更新缓存：钉钉返回的expireIn是有效秒数，我们计算一个过期的毫秒时间戳 // 预留60秒的缓冲时间，避免在临界点使用过期token tokenCache.value = accessToken; tokenCache.expireTime = now + (expireIn - 60) * 1000; console.log('获取并缓存了新token'); res.json({ success: true, access_token: accessToken, expire_in: expireIn, fromCache: false, }); } catch (error) { console.error('获取钉钉token失败：', error.response?.data || error.message); // 将钉钉的错误信息安全地返回给前端（避免泄露内部细节） const status = error.response?.status || 500; const message = error.response?.data?.message || '获取访问令牌失败，请稍后重试。'; res.status(status).json({ success: false, error: message, }); } }); // 一个示例代理接口：通过token获取部门列表 app.get('/api/dingtalk/departments', async (req, res) => { try { // 先获取token（会走缓存逻辑） const tokenResponse = await axios.get(`http://localhost:${PORT}/api/dingtalk/token`); if (!tokenResponse.data.success) { throw new Error(`获取Token失败：${tokenResponse.data.error}`); } const accessToken = tokenResponse.data.access_token; // 使用token调用钉钉业务API const deptResponse = await axios.get('https://api.dingtalk.com/v1.0/contact/departments', { headers: { 'x-acs-dingtalk-access-token': accessToken, // 钉钉API V1.0的鉴权头 }, params: { // 可根据需要传参，例如获取根部门 } }); res.json({ success: true, data: deptResponse.data, }); } catch (error) { console.error('获取部门列表失败：', error.message); res.status(500).json({ success: false, error: '获取部门信息失败', }); } }); app.listen(PORT, () => { console.log(`钉钉代理服务运行在 http://localhost:${PORT}`); });

4.3 环境配置与安全实践

在项目根目录创建.env文件，用于存储敏感信息。务必确保该文件被添加到.gitignore中，避免提交到代码仓库。

# .env DINGTALK_APP_KEY=你的AppKey DINGTALK_APP_SECRET=你的AppSecret FRONTEND_ORIGIN=http://localhost:8080 PORT=3000

关键安全提示：

• 永远不要提交.env文件：这是铁律。你的.gitignore文件里必须有一行.env。
• 生产环境配置：在真实的服务器（如云主机、容器）上，通过服务器的环境变量设置这些值，而不是文件。例如，在Linux服务器上使用export命令，或在Docker、K8s、PM2等部署工具中配置。
• 缓存策略：示例中使用了内存缓存，这在单进程服务中可行。但如果你部署了多个服务实例（负载均衡），内存缓存将不共享，会导致重复获取Token。生产环境务必使用外部缓存如Redis，所有实例共享同一个缓存。
• 错误处理：注意代码中错误处理的粒度。我们捕获了错误，并向前端返回了友好的、不暴露内部细节的错误信息，同时在后端日志中记录了详细错误，便于排查。

现在，运行npm run dev，你的代理服务就启动了。前端只需调用http://localhost:3000/api/dingtalk/token即可安全地获取到access_token。

5. 实战：构建Spring Boot代理服务

对于Java技术栈的团队，Spring Boot是构建此类代理服务的绝佳选择。它提供了强大的依赖管理、自动配置和丰富的生态。

5.1 项目创建与依赖配置

使用 Spring Initializr 或你的IDE创建一个新的Spring Boot项目。主要依赖包括：

• Spring Web: 用于构建RESTful API。
• Spring Cache和Redis(可选但推荐): 用于缓存access_token。
• Lombok(可选): 简化POJO代码。
• Spring Boot DevTools: 开发热加载。

你的pom.xml关键依赖部分会类似这样：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-cache</artifactId> </dependency> <!-- 如果使用Redis缓存 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>

5.2 核心服务层与缓存设计

首先，在application.yml或application.properties中配置钉钉应用信息和Redis（如果使用）。

# application.yml dingtalk: app-key: ${DINGTALK_APP_KEY:your_app_key_here} # 优先从环境变量读取 app-secret: ${DINGTALK_APP_SECRET:your_app_secret_here} api-base-url: https://api.dingtalk.com spring: cache: type: redis # 使用Redis作为缓存 redis: host: localhost port: 6379 # password: your_password # 如果有密码 # 允许跨域配置，也可以使用@CrossOrigin注解 # 这里配置全局CORS，允许前端域名访问

然后，我们创建一个配置类来读取钉钉配置，并定义一个HTTP客户端（这里使用Spring的RestTemplate）。

// DingTalkConfig.java import lombok.Data; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.client.RestTemplate; @Configuration @ConfigurationProperties(prefix = "dingtalk") @Data public class DingTalkConfig { private String appKey; private String appSecret; private String apiBaseUrl; @Bean public RestTemplate restTemplate() { return new RestTemplate(); } }

接下来是核心的服务类，负责与钉钉API交互并管理Token缓存。

// DingTalkService.java import com.fasterxml.jackson.annotation.JsonProperty; import lombok.Data; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.cache.annotation.Cacheable; import org.springframework.cache.annotation.CacheEvict; import org.springframework.http.*; import org.springframework.scheduling.annotation.Scheduled; import org.springframework.stereotype.Service; import org.springframework.web.client.RestTemplate; import org.springframework.web.util.UriComponentsBuilder; import java.util.HashMap; import java.util.Map; @Service @Slf4j public class DingTalkService { @Autowired private DingTalkConfig dingTalkConfig; @Autowired private RestTemplate restTemplate; /** * 钉钉获取Token的响应体 */ @Data public static class AccessTokenResponse { private String accessToken; @JsonProperty("expireIn") private Long expireIn; } /** * 获取AccessToken，并利用Spring Cache进行缓存。 * cacheNames = "dingtalkToken" 指定缓存名称。 * key是固定的，因为对于一个应用，Token是全局的。 * 除非强制刷新或过期，否则会直接返回缓存值。 */ @Cacheable(cacheNames = "dingtalkToken", key = "'accessToken'") public String getAccessToken() { log.info("缓存未命中，正在向钉钉请求新的AccessToken..."); String url = dingTalkConfig.getApiBaseUrl() + "/v1.0/oauth2/accessToken"; Map<String, String> requestBody = new HashMap<>(); requestBody.put("appKey", dingTalkConfig.getAppKey()); requestBody.put("appSecret", dingTalkConfig.getAppSecret()); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); HttpEntity<Map<String, String>> requestEntity = new HttpEntity<>(requestBody, headers); try { ResponseEntity<AccessTokenResponse> response = restTemplate.postForEntity( url, requestEntity, AccessTokenResponse.class); if (response.getStatusCode() == HttpStatus.OK && response.getBody() != null) { String token = response.getBody().getAccessToken(); log.info("成功获取AccessToken，有效期{}秒", response.getBody().getExpireIn()); return token; } else { throw new RuntimeException("钉钉API响应异常: " + response.getStatusCode()); } } catch (Exception e) { log.error("调用钉钉获取Token接口失败", e); throw new RuntimeException("获取钉钉访问令牌失败", e); } } /** * 一个示例：使用Token调用获取部门列表的接口 */ public Object getDepartmentList() { String accessToken = getAccessToken(); // 这里会自动走缓存 String url = dingTalkConfig.getApiBaseUrl() + "/v1.0/contact/departments"; HttpHeaders headers = new HttpHeaders(); headers.set("x-acs-dingtalk-access-token", accessToken); // V1.0鉴权头 HttpEntity<String> entity = new HttpEntity<>(headers); ResponseEntity<Object> response = restTemplate.exchange( url, HttpMethod.GET, entity, Object.class); // 使用Object接收动态JSON return response.getBody(); } /** * 定时任务：在Token过期前主动刷新缓存。 * 钉钉Token有效期7200秒，这里设定每7000秒（约1小时56分）执行一次，提前刷新。 * 使用@Scheduled需要主类加上@EnableScheduling */ @Scheduled(fixedDelay = 7000 * 1000) // 单位毫秒 @CacheEvict(cacheNames = "dingtalkToken", key = "'accessToken'") public void evictTokenCache() { log.info("定时任务：清除钉钉Token缓存，下次请求将获取新Token。"); // @CacheEvict注解会清除指定缓存，下次调用getAccessToken()将触发重新获取。 } }

5.3 控制器与全局CORS配置

最后，创建控制器（Controller）暴露API给前端，并配置全局CORS。

// DingTalkProxyController.java import org.springframework.beans.factory.annotation.Autowired; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; @RestController @RequestMapping("/api/dingtalk") // 可以在控制器级别配置CORS，更推荐使用全局配置 // @CrossOrigin(origins = "${frontend.origin:http://localhost:8080}") public class DingTalkProxyController { @Autowired private DingTalkService dingTalkService; @GetMapping("/token") public ResponseEntity<?> getToken() { try { String token = dingTalkService.getAccessToken(); return ResponseEntity.ok().body(Map.of("success", true, "access_token", token)); } catch (Exception e) { return ResponseEntity.status(500).body(Map.of("success", false, "error", "获取令牌失败")); } } @GetMapping("/departments") public ResponseEntity<?> getDepartments() { try { Object departmentList = dingTalkService.getDepartmentList(); return ResponseEntity.ok().body(Map.of("success", true, "data", departmentList)); } catch (Exception e) { return ResponseEntity.status(500).body(Map.of("success", false, "error", "获取部门列表失败")); } } }

为了更灵活地管理CORS，可以创建一个全局配置类：

// WebConfig.java import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.CorsRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; @Configuration public class WebConfig implements WebMvcConfigurer { @Value("${frontend.origin:http://localhost:8080}") private String frontendOrigin; @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") // 对所有/api/开头的路径生效 .allowedOrigins(frontendOrigin) // 允许的前端域名 .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") // 允许的HTTP方法 .allowedHeaders("*") // 允许所有头，这里解决了标题中‘Access-Control-Allow-Headers’的问题 .allowCredentials(true) // 是否允许发送Cookie .maxAge(3600); // 预检请求缓存时间（秒） } }

至此，一个基于Spring Boot的安全、高效、带缓存和定时刷新功能的钉钉API代理服务就搭建完成了。前端只需调用http://你的后端域名/api/dingtalk/token即可。

6. 前端调用改造与安全进阶考量

后端服务搭建好后，前端的改造就非常简单了。你只需要将原来直接指向api.dingtalk.com的请求，改为指向你自己的代理服务接口。

6.1 前端代码示例

// 假设之前错误的直接调用 // fetch('https://api.dingtalk.com/v1.0/oauth2/accessToken', {...}) // 改造后：调用自己的代理服务 async function fetchDingTalkToken() { try { const response = await fetch('https://api.myapp.com/api/dingtalk/token', { method: 'GET', // 如果需要，可以在这里添加你自己的认证头（如JWT） // headers: { 'Authorization': `Bearer ${userToken}` } }); const result = await response.json(); if (result.success) { console.log('获取到的Token:', result.access_token); // 存储token，用于后续业务API调用（同样是通过你的代理） return result.access_token; } else { throw new Error(result.error); } } catch (error) { console.error('从代理服务获取Token失败:', error); // 处理错误，如提示用户 } } // 获取部门列表示例 async function fetchDepartments() { const token = await fetchDingTalkToken(); // 先获取token // 然后通过代理服务获取部门数据 const deptResponse = await fetch('https://api.myapp.com/api/dingtalk/departments'); // ... 处理数据 }

6.2 安全进阶：为代理接口添加认证

现在，你的代理接口https://api.myapp.com/api/dingtalk/token是公开的。这意味着任何人知道了这个地址，都可以免费获取你应用的access_token（虽然拿不到AppSecret），并消耗你的API调用配额。为了防止滥用，你必须为这个代理接口加上一层认证。

常用方案：

1. API密钥/令牌（简单）：为你的前端分配一个固定的API Key，前端在请求代理接口时，在Header（如X-API-Key）中携带。后端验证这个Key是否有效。这种方式实现简单，但Key泄露风险依然存在。
2. 用户会话认证（推荐）：如果你的H5应用本身有用户登录体系（如JWT、Session），那么代理接口应该要求用户先登录。后端在/api/dingtalk/token接口中，校验请求携带的登录凭证（如JWT Token），确认是合法用户后才去钉钉获取Token。这样，访问权限就和你自己的业务用户体系绑定了。
3. 短期令牌（如OAuth2.0 Client Credentials for Frontend）：实现一个更复杂的流程，前端先向你的认证服务器获取一个短期、权限受限的访问令牌，再用这个令牌去访问代理接口。这提供了更细粒度的控制和安全性。

以JWT为例的简单改造（Spring Boot端）：

// 在Controller的方法上添加认证要求 @GetMapping("/token") public ResponseEntity<?> getToken(@RequestHeader("Authorization") String authHeader) { // 1. 验证JWT Token的有效性 if (!jwtUtil.validateToken(authHeader)) { return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("未授权"); } // 2. 从Token中解析用户信息，可进行更细粒度的权限检查 // String userId = jwtUtil.getUserIdFromToken(authHeader); // 3. 验证通过，执行原有获取钉钉Token的逻辑 try { String token = dingTalkService.getAccessToken(); return ResponseEntity.ok().body(Map.of("success", true, "access_token", token)); } catch (Exception e) { return ResponseEntity.status(500).body(Map.of("success", false, "error", "获取令牌失败")); } }

6.3 部署与监控要点

• HTTPS是必须的：生产环境务必为你的代理服务域名（api.myapp.com）配置SSL证书，使用HTTPS协议。这是保护数据传输安全的基础。
• 限流与防刷：在代理服务层（如使用Spring Boot的Resilience4j或Sentinel，Node.js的express-rate-limit）添加限流策略，防止单个IP或用户恶意刷你的代理接口，导致频繁调用钉钉API而被限流。
• 日志与监控：记录所有代理接口的访问日志，包括请求IP、用户、时间、结果等。监控Token获取的频率和错误率，异常时及时告警。
• 多环境配置：区分开发、测试、生产环境，使用不同的钉钉应用密钥（AppKey/Secret）和环境变量。

7. 其他方案辨析与常见陷阱

在解决这个问题的过程中，你可能会在网上看到其他一些“取巧”的方案，这里需要特别辨析一下，并指出其中的陷阱。

7.1 误区一：尝试配置浏览器或服务器绕过CORS

• 浏览器插件禁用CORS：这仅在本地开发调试时可能有用，你无法控制终端用户的浏览器。绝对不可作为解决方案。
• 本地开发服务器代理：在Vue CLI、Create React App或Webpack Dev Server中，可以配置proxy。这本质是在本地开发环境启动了一个微型代理，将前端请求转发到钉钉API。这仅适用于本地开发，解决了开发时的跨域问题，但同样没有解决AppSecret暴露的前端代码中的根本安全问题。生产环境不能使用此配置。
• Nginx反向代理：这是一个可行的架构补充，但不是核心解决方案。你可以在Nginx中配置一个路由规则，将/dingtalk-api/路径的请求反向代理到https://api.dingtalk.com，并在Nginx层添加CORS头。但这仍然面临两个问题：(1) 获取Token的请求（包含AppSecret）仍然是从你的服务器发出，你需要把AppSecret放在Nginx配置或后端，这又回到了服务端代理的模式；(2) 你无法在Nginx层实现Token缓存、业务逻辑和细粒度的安全认证。因此，Nginx反向代理通常用于代理那些无需携带敏感信息、只需附加通用Token的业务API，而不是获取Token的入口。

7.2 误区二：使用JSONP

钉钉的API是HTTPS且返回JSON格式，现代API设计基本都不支持JSONP。JSONP只适用于GET请求且需要服务端返回特定JavaScript函数调用包装的数据，钉钉API显然不满足条件。此路不通。

7.3 一个真实的“坑”：Token缓存与多实例部署

这是在实际部署中最容易踩的坑。假设你的代理服务部署了两个实例（Instance A和B），并使用了内存缓存。

1. 用户请求到达Instance A，A发现缓存无Token，向钉钉请求并缓存。
2. 用户下一个请求被负载均衡到Instance B，B的内存缓存是空的，于是它又向钉钉请求一个新的Token。
3. 结果：同一个应用，短时间内获取了多个有效Token，不仅浪费，还可能触发钉钉的未知限制。

解决方案：使用分布式缓存，如Redis。无论是Node.js还是Spring Boot，都将Token存储在Redis中，所有服务实例共享同一份缓存数据。Spring Boot的@Cacheable配合Redis starter可以轻松实现。Node.js则需要使用ioredis或node-redis客户端库来读写Redis。

7.4 钉钉API版本与鉴权头变化

钉钉开放平台API有V1.0和V2.0之分，它们的鉴权方式不同：

• V1.0：在请求头中传递x-acs-dingtalk-access-token: {access_token}。
• V2.0：在请求头中传递x-acs-dingtalk-access-token: {access_token}，但基础路径和部分参数可能有变化。

在编写代理服务调用业务API时，务必根据钉钉官方文档确认API的版本和正确的鉴权头、请求格式。本文示例使用的是V1.0的获取Token和部门列表接口。