Appearance
Nacos 平台操作
Nacos 控制台适合日常确认：配置有没有发布出来、服务有没有注册成功、集群节点是不是在线、历史版本能不能看到。命令行动态验证和脚本自动化更方便，控制台更适合看状态和人工确认。
一、控制台入口——3.x 的端口变更
Nacos 3.x 控制台端口默认是 8080，路径是 /next/：
text
http://192.168.10.11:8080/next/服务端 API 仍然使用 8848：
text
http://192.168.10.11:8848/nacos/Nacos 2.x 旧资料里经常直接访问 8848/nacos 打开控制台。3.x 访问 8848 会看到提示，告诉用户控制台在 8080。8848 更偏向服务端 API 和客户端通信端口。排查时先确认：访问的是控制台还是 API 端口。
首次访问控制台时要求初始化管理员 nacos 的密码。实验环境用 nacos/nacos，真实环境需要及时更换并配合权限控制。
二、命名空间
控制台顶部命名空间下拉框用于切换当前操作范围，默认显示 public。
命名空间的常见用法：
| 命名空间 | 用途 |
|---|---|
public | 默认空间，实验或少量公共配置 |
dev | 开发环境 |
test | 测试环境 |
prod | 生产环境 |
环境隔离用命名空间做第一层。不同 namespace 下可以有完全同名的 dataId 和服务名。排查配置不生效或服务找不到时，命名空间是第一批核对项——开发在 dev 查、应用在 prod 跑，自然什么都看不到。
三、配置列表
配置列表展示 Data ID、Group、格式和操作入口。发布配置时至少要写清这几个字段——排查"应用读不到配置"就是围绕它们逐一比对。
配置详情页的三个区域：
| 区域 | 做什么 |
|---|---|
| 基本信息 | dataId、group、namespace、格式——不可改的标识 |
| 配置内容 | 实际下发给应用的文本——修改的主体 |
| 历史版本 | 变更记录、内容对比和回滚入口 |
编辑前先复制当前内容或确认历史版本可用。发布后业务异常，先看历史版本对比差异，再决定是回滚还是继续修正。
配置是 YAML 时，缩进、冒号、列表格式要保证语法正确。控制台能保存只代表文本存进去了，不代表应用解析一定成功。
四、服务列表
服务列表展示服务名、分组、集群数、IP 数、健康实例数和操作入口。
几个数字的含义：
| 字段 | 说明 |
|---|---|
| 集群数 | 该服务下有多少集群分组 |
| IP 数 | 注册了多少实例 IP |
| 健康实例数 | 健康检查通过的实例数量——调用方真正用的是这个数 |
| 触发保护阈值 | 保护阈值触发状态 |
服务名存在不等于服务可用。IP 数是 1、健康实例数是 0，说明注册记录还在，但健康检查没通过——调用方拿不到这个实例。控制台 IP 数只是"记录了几个"，"调用方实际拿到几个"要结合查询 API 的返回和客户端日志判断。
五、集群管理
集群管理页面能直观看到节点状态：节点数量是否和预期一致、状态是否都是 UP、版本是否统一。日常巡检这三项是重点。
节点元数据里可以看到版本和 Raft 相关信息。如果某个节点版本和其他两台不同，大概率是升级时软链接指向了不同版本目录。
六、AI 注册中心
Nacos 3.x 控制台菜单里新增了 AI 注册中心，包含以下子模块：
| 菜单 | 作用倾向 |
|---|---|
| Skill 管理 | 管理可复用能力描述 |
| Prompt 管理 | 管理 Prompt 模板 |
| Agent 管理 | 管理 Agent 描述和发现信息 |
| AgentSpec 管理 | Agent 规范描述（界面标为 Beta） |
| MCP 管理 | MCP 服务入口管理 |
这块更接近 AI 应用的"能力目录"和"发现入口"——把 AI 应用中的 Skill、Prompt、Agent、MCP 这些对象放进注册中心的语境里，让它们也像微服务一样可以被发现和引用。它不是把 Agent 当 Linux 进程来启动、停止和重启的平台。Agent 怎么运行、怎么调用模型、怎么编排任务，仍然由具体 Agent 框架决定。
日常运维里使用频率最高的仍然是配置中心、服务发现和集群状态这三个板块。