保存服务器OP的核心操作是：在服务端控制台输入 /op 玩家名，或者直接编辑 ops.json / permissions.json 文件，OP权限会自动存储在服务器文件中，正常情况下重启不会丢失。
如果你的OP重启后总消失,多半是没找对服务端类型对应的配置文件，或者操作时选错了保存方式，下面我会把Java版和基岩版分开讲清楚，附上验证方法。
为什么我的世界服务器op保存不了？先分清Java版和基岩版
很多玩家遇到OP丢失,第一反应是命令没输对，实际上是服务端类型不同，保存OP的机制完全不一样，行业共识认为，90%的OP保存问题都出在版本混淆上。
Java版：权限写在ops.json里
Java版服务器（如Paper、Spigot、Purpur、Forge）使用 ops.json 文件存储OP列表，当你执行 /op 玩家名 后，服务端会立刻把玩家信息写入这个文件，并且实时保存，不需要额外执行保存命令。
- 文件位置：服务端根目录
- 文件格式：JSON数组
- 关键字段：
name（玩家名）、uuid（玩家唯一标识）、level（权限等级 1-4）
基岩版：权限写在permissions.json里
基岩版服务器（如BDS官方服务端）使用 permissions.json 管理OP权限，这个文件默认不存在，需要手动创建，或者通过控制台命令生成。
- 文件位置：服务端根目录
- 文件格式：JSON数组
- 关键字段：
name或xuid（玩家标识）、permission（权限级别）
| 对比项 | Java版 | 基岩版 |
|---|---|---|
| 配置文件 | ops.json | permissions.json |
| 默认是否存在 | 首次启动自动生成 | 不存在，需手动创建 |
| OP等级 | 1-4级 | visitor/member/operator |
| 保存方式 | 命令自动写入 | 命令自动写入 |
如果你用的租赁服务器面板，操作界面可能不同，但底层文件逻辑完全一致，无论你购买的是国内面板服还是海外VPS，OP保存机制都不会变。
我的世界服务器op配置文件在哪？完整路径与手动保存方法
不同服务端核心,配置文件的位置虽然有细微差异，但都在服务端根目录下，不会跑到别的地方，这里给出实际操作的完整路径。
Java版服务端定位ops.json
以最常见的Paper服务端为例：
# 服务端根目录结构 /你的服务器文件夹/ ├── ops.json # OP列表文件 ├── server.properties # 服务器核心配置 ├── world/ # 世界存档文件夹 └── paper.yml # Paper专用配置
手动添加OP的两种方式：
- 服务端控制台输入
/op 玩家名，然后按回车 - 用记事本打开
ops.json，手动添加一段JSON代码
{
"uuid": "玩家的UUID",
"name": "玩家名",
"level": 4,
"bypassesPlayerLimit": false
}
基岩版手动创建permissions.json
如果你的基岩版服务器控制台输入 /op 玩家名 提示成功，但重启后权限丢失，请检查根目录是否生成了 permissions.json，没有的话，手动新建一个，填入以下内容：
[
{
"name": "玩家名",
"permission": "operator"
}
]
保存后重启服务器,权限就会固定下来，需要注意，基岩版的 permissions.json 与 allowlist.json（白名单）是两个不同的文件，不要混用。
关于手动编辑文件的优先级
手动编辑配置文件后,需要重启服务器或者执行 /reload 命令才会生效，而用 /op 命令添加的OP，则无需重启，立即生效并保存。
服务器重启后OP消失的排查清单
如果你的OP在重启后消失,按以下顺序排查，多数情况下能直接找到问题根源，近年来，多数OP丢失案例都和插件冲突或UUID不匹配有关。
排查点一：是否开启了正版验证
Java版服务器在 server.properties 中有一项 online-mode：
online-mode=true（正版验证开启）：ops.json 同时记录名字和UUID，玩家上线时校验UUIDonline-mode=false（离线模式）：部分服务端只记录名字，遇到同名玩家会覆盖权限
典型症状：离线模式下，如果两个玩家同名，后进服务器的玩家会顶掉前一个玩家的OP，解决方案是让玩家修改游戏ID，或者保留正版验证。
排查点二：权限管理插件是否接管了OP
Spigot/Paper服务端安装 LuckPerms 等权限插件后，插件的权限体系和原版OP是两套系统，插件权限不写入 ops.json，而是写入插件的数据库或YAML文件。
如果你的服务器同时存在原版OP和插件权限,重启后插件权限丢失，问题出在插件配置，而不是服务端本身，此时应该去 plugins/LuckPerms/ 目录下检查存储文件。
排查点三：控制台和游戏内命令的区别
服务端控制台执行的命令有最高优先级,而游戏内输入 /op 需要玩家本身有OP权限或处于创造模式，如果你在游戏内执行 /op 提示无权限，请到控制台执行。
排查点四：服务器面板的自动重启机制
部分租赁面板会在服务器无响应时自动重启,并在重启时从备份点恢复文件，如果你的面板开启了”故障自动回滚”功能，即使OP保存成功，也可能被还原到之前的状态，这时候需要到面板后台关闭自动回滚，或者手动触发一次完整备份。
如何验证OP已彻底保存？三步检测法
完成OP添加后,不要急着关服务器，花一分钟做验证，能省下后面所有麻烦。
- 查看配置文件内容：打开 ops.json，确认玩家名和UUID已在列表内
- 执行查询命令：控制台输入
/op（不带参数），会列出当前所有OP玩家 - 重启服务器测试：完全停止进程，重新启动，再次输入
/op确认列表还在
不同服务端的细节差异
- Fabric服务端：需要安装Fabric API后才能使用
/op命令，否则会提示命令未知 - Sponge服务端：权限系统默认由插件管理，原版
/op命令可能失效 - Forge服务端：部分模组会覆盖权限系统，需要查看模组文档确认
Q&A：我的世界服务器保存OP常见问题
我输入 /op 玩家名 后提示成功，但玩家仍没有管理员权限，怎么回事？
大概率是玩家UUID不匹配，在离线模式下，玩家更换ID后UUID会变化，ops.json里存的是旧UUID，你可以在控制台输入 /pardon 玩家名 移除旧记录，再重新 /op 玩家名，如果是正版服务器，确认玩家登录时用的微软账号是否和之前一致。
给朋友OP后，他进服提示”你不是OP”，但ops.json里明明有他的记录？
检查服务端是否开启了 BungeeCord/Velocity 代理，在代理端，子服务器的OP判断以代理端分配的UUID为准，你需要在每个子服务器里分别添加OP，或者在代理端统一配置权限同步插件，否则即使主服务器有记录，子服务器也不会认可。
基岩版和Java版混合服务器（如Geyser），OP保存方式一样吗？
Geyser中转服的本质是让基岩版玩家以Java版身份进入,所以OP保存方式完全遵循Java版规则，基岩版玩家在Geyser服中获得的OP会写入 ops.json，而不会写入 permissions.json，如果基岩版玩家想要基岩原版服的OP，则必须使用基岩版服务端才能实现。
保存OP归根结底是正确的命令加正确的配置文件,选对服务端类型，操作不会超过一分钟，你在配置过程中只要保证控制台执行命令、重启后验证这两个动作，OP就能长期生效。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793973.html
