Nacos 配置管理
配置管理是 Nacos 的另一半能力：把散落在各应用里的配置文件集中存放，改一处、全网生效。本章用控制台与 OpenAPI 各演示一遍"发布/获取/回滚"。
发布配置（控制台）
"配置管理 → 配置列表 → 新建配置"，填写四个字段后点发布：
| 字段 | 填写示例 | 说明 |
|---|---|---|
| dataId | order-service.properties | 配置标识，后缀决定格式 |
| group | DEFAULT_GROUP | 分组 |
| 配置格式 | properties | properties/yaml/text/json |
| 配置内容 | timeout=5000 | 配置正文，原样保存 |
发布即持久化到存储，并触发对客户端的变更通知（机制见第 9 章）。
发布配置（OpenAPI）
发布走 POST /nacos/v1/cs/configs，把 dataId、group、content 作为表单参数提交：
curl -X POST 'http://localhost:8848/nacos/v1/cs/configs' \
-d 'dataId=order-service.properties&group=DEFAULT_GROUP&content=timeout=5000'
# 输出：true
content 是原始文本，Nacos 按 dataId 的后缀（.properties/.yaml 等）识别解析格式。
获取配置
用 GET /nacos/v1/cs/configs 拉取配置原文：
curl -X GET 'http://localhost:8848/nacos/v1/cs/configs?dataId=order-service.properties&group=DEFAULT_GROUP'
# 输出：timeout=5000
dataId 或 group 不存在时返回 404 及错误提示，可用它做存在性探测。
dataId 命名规范建议
dataId 既要可读又要成体系，社区常用的规则是"应用名-环境.后缀"：
- 形如 order-service-dev.properties、order-service.yaml，一看便知属于谁
- 后缀就是格式：.properties 按 properties 解析，.yaml 按 YAML 解析
- 环境差异既可放中间段（-dev/-prod），也可用命名空间隔离（见第 8 章），两种风格二选一即可
- 多个应用共用的公共配置单独建 dataId（如 common.yaml），配合共享配置机制使用
客户端获取配置（Java）
不依赖 Spring 时，直接用 nacos-client 的 ConfigService 拉取：
// 需放入 main 方法运行，并捕获 NacosException
Properties props = new Properties();
props.put("serverAddr", "localhost:8848");
ConfigService cs = NacosFactory.createConfigService(props);
String content = cs.getConfig("order-service.properties", "DEFAULT_GROUP", 3000);
System.out.println(content); // 输出：timeout=5000
参数含义：dataId、group、读取超时（毫秒）。若需要"变了就通知"，见第 9 章 addListener。
变更历史与回滚
每次发布（包括控制台、OpenAPI）都会留一条历史记录，误改后回滚即可：
- 配置列表点 dataId 进入"配置详情"
- 打开"历史版本"，比对各版本内容与发布时间
- 选中目标版本点"回滚"，系统用该版本内容重新发布一次
回滚不是物理还原而是"再发布"，因此同样对客户端即时生效，且本身也会生成新历史。
删除配置
配置不用了可以删除（注意先确认没有客户端在使用）：
curl -X DELETE 'http://localhost:8848/nacos/v1/cs/configs?dataId=order-service.properties&group=DEFAULT_GROUP'
# 输出：true
小结
配置管理的日常闭环是：控制台或 OpenAPI 发布配置 → 客户端 getConfig 拉取 → 出问题时在历史版本里选版回滚。再加上 dataId 命名规范，一套配置治理体系就立起来了；更细的多环境组织见下一章。