MintHCM 常用 CLI 命令详解

MintHCM 4.3.5 把日常运维收敛到一个命令行入口：应用根目录下的 MintCLI。这是一个基于 Symfony Console 的管理工具，覆盖安装、升级、演示数据、Elasticsearch 索引、实例修复、OAuth2 密钥、SSO 绑定七大类操作。本文在《MintHCM Debian 12 安装部署指南（Apache + MariaDB + Elasticsearch 实测）》部署出的同一台 Debian 12 服务器上，对全部管理命令逐个实测，回显逐行照录（终端彩色输出已去除颜色码，内容未做任何增删）；参数与配置的联动语义见《MintHCM 配置参数详解》，项目背景与版本信息见《MintHCM 介绍与选型指南》。

实测环境基线：Debian 12 / Apache 2.4.68 / PHP 8.2.35 / MariaDB 10.11.19 / Elasticsearch 7.17.28 / MintHCM 4.3.5，应用根 /var/www/minthcm，数据库名 minthcm（数据库账号 root / q1w2e3r4），应用管理员 admin / q1w2e3r4。

一、MintCLI 入口与运行方式

1.1 入口文件与源码结构

/var/www/minthcm/MintCLI              # 1520 字节的 PHP 入口脚本（#!/usr/bin/php）
/var/www/minthcm/legacy/MintCLI/      # 实现（Composer autoload 挂在 legacy 下）
├── src/Commands/                     # 11 个命令类，其中 10 个注册可见，Test 为内部工具未注册
├── src/Questions/                    # 交互式问答（安装 17 问、模块选择等都在这里）
└── src/Installer/                    # 安装子服务（DatabaseInstaller、BackendInstaller 等）

入口脚本只有三行有效逻辑：定义 sugarEntry、加载 legacy/MintCLI/vendor/autoload.php、启动 Symfony Console 应用。命令注册名与实现类一一对应（如 instance:rebuild → src/Commands/RepairAndRebuild.php）。

1.2 怎么跑

cd /var/www/minthcm
sudo -u www-data ./MintCLI <命令>

两条纪律：

工作目录必须是应用根 /var/www/minthcm。命令内部按相对路径读写（如 demodata:dump 落盘到 legacy/install/demo_data/），换目录会读写到错误位置。
以 Web 服务用户 www-data 身份运行。应用文件属主是 www-data（部署篇第六节），MintCLI 会生成缓存与密钥文件，用 root 跑会留下 root 属主文件，破坏权限一致性——upgrade 命令为此专门提供 --owner 选项，默认值就是 www-data:www-data。

下文所有回显均在上述方式下抓取，命令行统一省略 sudo -u www-data 前缀。

1.3 全局选项

选项	作用
`-h, --help`	显示某命令的帮助；不带命令时显示命令清单
`-q, --quiet`	静默模式，不输出任何消息
`-V, --version`	显示 Console 应用版本
`--ansi` / `--no-ansi`	强制开启/关闭彩色输出（重定向到文件做记录时建议 `--no-ansi`）
`-n, --no-interaction`	不发起任何交互提问，一律取默认值（脚本化场景慎用）
`-v` / `-vv` / `-vvv`	三档详细输出，`-vvv` 可看到 SQL 等调试信息

1.4 命令清单：`./MintCLI list`

Console Tool

Usage:
  command [options] [arguments]

Options:
  -h, --help            Display help for the given command. When no command is given display help for the list command
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi|--no-ansi  Force (or disable --no-ansi) ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Available commands:
  completion                     Dump the shell completion script
  help                           Display help for a command
  install                        Install MintHCM system
  list                           List commands
  upgrade                        Upgrade MintHCM to a specific version tag
 demodata
  demodata:dump                  Demo Data Dump
  demodata:install               Demo Data Install
 elasticsearch
  elasticsearch:reindex          Reindex ElasticSearch
  elasticsearch:reindexModule    Reindex selected ElasticSearch Module
 instance
  instance:rebuild               Repair and Rebuild MintHCM Instance
 oauth2
  oauth2:createKeys              Create OAuth2 Keys
  oauth2:regenerateClientSecret  Regenerate Frontend OAuth2 Client Secret
 users
  users:resetOidcBinding         Reset the OIDC (SSO) subject binding of one user or of all users

EXIT=0

10 个业务命令按命名空间分组：demodata（演示数据）、elasticsearch（搜索索引）、instance（实例维护）、oauth2（API 密钥）、users（SSO 绑定），另有顶层的 install 与 upgrade。completion/help/list 是 Symfony Console 自带的三个内置命令。

二、命令速查表

命令	作用	是否有破坏性	本文实测情况
`install`	全新安装 MintHCM	高：会建库导表、覆写配置	安装时执行过一次（部署篇第五节 17 问实录）；已装实例不可重复执行
`upgrade`	升级到指定版本 tag	高（改代码、跑迁移）	未执行：实例已是 4.3.5 最新版，无目标 tag 可升，语义按 help 与源码说明
`demodata:dump`	把库内数据导出为演示数据种子	低（只写 `legacy/install/demo_data/`）	已实测，EXIT=0，产出 99 个 SQL 文件
`demodata:install`	向库内灌入演示数据	中（插入大量数据）	安装流程执行过一次；未对现有库重复灌入
`elasticsearch:reindex`	全量重建 ES 索引	低（删建 `<前缀>_*` 索引后重建）	已实测，含故障复现与修复，EXIT=1→0
`elasticsearch:reindexModule`	单模块重建 ES 索引	低	已实测 Users 模块，EXIT=0
`instance:rebuild`	修复并重建实例	低（重建 JS/清缓存）	已实测，EXIT=0
`oauth2:createKeys`	生成 OAuth2 JWT 密钥对	中（密钥轮换使旧令牌失效）	已实测，密钥文件已更新，EXIT=0
`oauth2:regenerateClientSecret`	重生成前端 OAuth2 客户端密钥	低（前端运行时自动拉取新密钥）	已实测，DB 哈希已更新且 API 返回一致，EXIT=0
`users:resetOidcBinding`	重置用户的 OIDC(SSO) 绑定	低	已实测三种分支，退出码 0/2/1

三、安装与升级：`install` / `upgrade`

3.1 `install` —— 全新安装

Description:
  Install MintHCM system

Usage:
  install

Help:
  This command allows you to install MintHCM system.

无任何参数与选项，全程交互问答：系统 URL、数据库连接、语言、是否装演示数据等 17 项。部署篇第五节有逐问逐答的完整实录（含每一项的默认值与本文取值），此处不重复。

install 只用于全新安装，不能对已装实例重复执行：其内部会经 DatabaseInstaller 建库导表（部署篇实测建出 341 张表）、覆写 legacy/config.php，等于把实例打回出厂状态。源码层面它是多个子安装器的编排：src/Installer/ 下的 DatabaseInstaller、BackendInstaller、BaseConfigurationInstaller、FileManager、ServerConfigManager 依次执行，任何一步失败都会抛出对应的异常类（src/Installer/Exceptions/ 下 10 余个），例如 DBConnectionException 就是数据库连不上时的标准报错。

3.2 `upgrade` —— 升级到指定版本

Description:
  Upgrade MintHCM to a specific version tag

Usage:
  upgrade [options]

Options:
  -t, --tag=TAG            Target version tag to upgrade to (e.g. 4.3.1)
      --skip-checks        Skip environment requirement checks (not recommended)
      --git-user=GIT-USER  Git username for HTTPS authentication
      --git-pass=GIT-PASS  Git password or personal access token for HTTPS authentication
  -y, --yes                Automatically confirm all prompts (for non-interactive/batch use)
      --owner=OWNER        File owner to set as user:group (e.g. www-data:www-data) [default: "www-data:www-data"]
  -h, --help               Display help for the given command. When no command is given display help for the list command
  ...

Help:
  Upgrades MintHCM to the specified git tag. Reads version requirements directly from the target tag without checking it out first.

要点：

以 git tag 为升级单位，如 ./MintCLI upgrade --tag=4.3.6。它直接从目标 tag 读取版本要求做环境检查（不必先 checkout），--skip-checks 可跳过检查但官方标注 not recommended。
支持私有仓库凭据：--git-user/--git-pass 用于 HTTPS 认证的私有 git 源。
-y 面向无人值守：自动确认全部提示。
七步流水线（源码 steps 数组，按序执行）：pre_upgrade → fetch_and_checkout → apply_permissions → instance_rebuild → migrations → post_upgrade → finally_apply_permissions。注意升级内置了一次 instance:rebuild。
断点续跑：每完成一步就保存状态，中断后再次执行同一 --tag 命令会提示从断点继续，已完成的步骤显示 Skipping (already completed): <步骤>。
跨越式升级受限：源码会校验目标 tag 与当前版本的中间版本链，跨度太大时直接报错 Cannot upgrade directly from X to Y. Multiple intermediate upgrades are required. 并给出逐级路径。

本文未实际执行 upgrade：实测实例已是 4.3.5（《介绍与选型指南》发布日核查的最新版），没有可升级的目标 tag；以上语义全部来自 help 原文与命令源码。

四、演示数据：`demodata:dump` / `demodata:install`

4.1 `demodata:dump` —— 把现有库导出为演示数据种子

这一对命令是"种子数据"工作流的两端：dump 从一个你调好的实例里导出数据文件，install 把种子文件灌进新实例。

实测（回答交互问题 WithFiles 为 n，即不连带导出上传附件文件）：

$ echo n | ./MintCLI demodata:dump

 Provide all of the information to start dumping data.

 Demo data is dumping. It will take a while.

 223/223 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

 [OK] Demo Data has been dumped successfuly

EXIT=0

产物验证：

$ ls legacy/install/demo_data/ | head -6
acl_actions.sql
acl_roles.sql
acl_roles_actions.sql
acl_roles_users.sql
allocations.sql
applications.sql

$ ls legacy/install/demo_data/ | wc -l
99

行为解析（源码依据）：命令遍历 SHOW TABLES 的全部表并剔除 src/Configs/demo_data.php 里的 blacklist_tables（实测迭代 223 张表），逐表把行数据写成 INSERT 语句落到 legacy/install/demo_data/<表名>.sql——341 张表里只有 99 张有数据落盘，其余为空表不生成文件。WithFiles 回答 y 时还会把 legacy/upload/ 里的附件一并复制到 legacy/install/demo_data/files/。

注意：dump 会覆盖发行包自带的演示数据 SQL。导出的目录就是 demodata:install 与 install 流程读取的种子源，想恢复官方演示数据需重新解包发行版。

4.2 `demodata:install` —— 向库内灌入演示数据

Description:
  Demo Data Install

Usage:
  demodata:install

Help:
  This command allows you to install demo data from file to your system.

它读取 legacy/install/demo_data/ 下的种子文件并批量插入数据库。部署实例中的 69 名员工、19 个用户等演示数据，就是 install 交互流程最后一问选择安装演示数据时由这条链路灌入的（部署篇第五节问答实录第 17 项）。本文未对现有库重复执行——再跑一遍会向已含演示数据的库里再插入一套数据，污染业务表；确需重灌应在新库或清库后进行。

五、Elasticsearch 索引：`elasticsearch:reindex` / `elasticsearch:reindexModule`

列表视图与全局搜索都走 ES（C1 配置篇 2.5 节），这两条命令是索引层的两大开关：全量重建与单模块重建。

5.1 全量重索引 `elasticsearch:reindex` —— 附一次故障实录

什么时候必须跑：修改了 elasticsearch_index_prefix（C1 第九节实录 3）、修改了 ES 连接参数、或大批量导数之后列表/搜索查不到数据。

故障复现。把 legacy/config.php 里 search.ElasticSearch.host 从 localhost:9200 改成空值 :（模拟配置被破坏），命令立即报错：

$ sed -i "s|localhost:9200|:|" legacy/config.php && ./MintCLI elasticsearch:reindex

Reindexing ElasticSearch

========================

 [ERROR] There was an error during execution: InvalidArgumentException: Failed to
         parse Host URL 'http://:' in
         /var/www/minthcm/legacy/lib/Search/ElasticSearch/ElasticSearchClientBuilder.p
         hp:108
         Stack trace:
         #0
         /var/www/minthcm/legacy/lib/Search/ElasticSearch/ElasticSearchClientBuilder.p
         hp(182):
         SuiteCRM\Search\ElasticSearch\ElasticSearchClientBuilder::sanitizeHost()
         #1
         /var/www/minthcm/legacy/lib/Search/ElasticSearch/ElasticSearchClientBuilder.p
         hp(68):
         SuiteCRM\Search\ElasticSearch\ElasticSearchClientBuilder::loadFromSugarConfig()
         #2
         /var/www/minthcm/legacy/lib/Search/ElasticSearch/ElasticSearchIndexer.php(99):
         SuiteCRM\Search\ElasticSearch\ElasticSearchClientBuilder::getClient()
         #3 /var/www/minthcm/legacy/MintCLI/src/Commands/ElasticSearchReindex.php(49):
         SuiteCRM\Search\ElasticSearch\ElasticSearchIndexer->__construct()
         ...

退出码 EXIT=1。两个定位线索：parse Host URL 'http://:' 说明 ES 客户端是拿 host:port 拼接 URL 的，host 为空只剩冒号；栈帧 loadFromSugarConfig() 说明它读的是 legacy 主配置（C1 2.5 节）而非 api 层配置。

修复并成功执行。恢复 'host' => 'localhost:9200' 后重跑（回显中 [=] 为进度节点、[@] 为信息节点，带时间戳；本文实测约 350 行，中间的逐模块行节选）：

[=][13:54:40] Starting indexing procedures
[@][13:54:40] Indexing is performed using JsonSerializerDocumentifier
[@][13:54:40] A full indexing will be performed
...
[@][13:54:49] Indexed 19/19 - 100% records for module Users (free memory: -46 MB)
[@][13:54:49] Indexed 19/19 Users
...
[@][13:54:56] Indexed 0/0 MCPDocCategories
[@][13:54:56] Indexed 0/0 MCPDocumentation
[@][13:54:56] 92 modules, 1265 records and 18313 fields indexed in 16.395 s
[@][13:54:56] Average speed is 1116.970 fields/s
[@][13:54:56] It would take ~43m 12s for 200,000 records, assuming a linear expansion
[=][13:54:56] Indexing complete

EXIT=0

逐行解读：

A full indexing will be performed：全量模式，先删除再重建 <前缀>_* 全部索引（前缀 1e4a 来自 config.php 201 行，见 C1 2.5 节）。
中间每个模块两行：进度百分比行与汇总行，如 Users 模块 Indexed 19/19 Users；括号里的 free memory 是工具自带的内存统计口径，在小内存环境可能显示负值，不影响索引结果（本次索引正常完成）。
收尾三行统计是容量规划依据：本实例 92 个模块、1265 条记录、18313 个字段耗时 16.4 秒；按线性外推 20 万条记录约需 43 分钟。

5.2 单模块重索引 `elasticsearch:reindexModule`

只针对一个模块删建索引并重灌，秒级完成，适合改了某个模块的搜索配置或数据修复后快速刷新。实测重索引 Users 模块（命令发起后会交互式提问模块名，Module Name: 处输入 Users）：

Module Name:
[@][13:55:11] Modules have been set to ["Users"]
[=][13:55:11] Starting indexing procedures
[@][13:55:11] Indexing is performed using JsonSerializerDocumentifier
[@][13:55:11] A full indexing will be performed
[@][13:55:11] Removed index '1e4a_users'
[@][13:55:11] Loading mapping file /var/www/minthcm/legacy/lib/Search/ElasticSearch/defaultParams.yml
[@][13:55:11] Created new index '1e4a_users'
[=][13:55:11] Indexed 19/19 - 100% records for module Users (free memory: -32 MB)
[@][13:55:11] Indexed 19/19 Users
[@][13:55:11] 1 modules, 19 records and 276 fields indexed in 0.266 s
[=][13:55:11] Indexing complete

EXIT=0

值得注意的三点：索引名是 <前缀>_<小写模块名>（1e4a_users）；mapping 来自 legacy/lib/Search/ElasticSearch/defaultParams.yml；同一次执行里先 Removed index 再 Created new index，即单模块重建同样以删建为手段，执行期间该模块的搜索会短暂空窗。

六、实例维护：`instance:rebuild`

改过语言包、模板、视图元数据，或页面出现白屏/样式错乱/接口 500 而日志无果时，第一反应就是这条命令。完整实测回显：

$ ./MintCLI instance:rebuild

 Repairing and Rebuilding MintHCM Instance

=========================================

 Rebuilding MintHCM instance...

 Rebuilding javascript...

 Clearing api cache...

 Repairing oauth keys permissions...

 [OK] The instance has been rebuilt successfully

VTOOLS2 REBUILD BEGIN.
REBUILD FINISHED SUCCESSFULLY.
EXIT=0

它按序做四件事（对应源码中的四个服务）：

Rebuilding MintHCM instance（RepairAndRebuildLegacyService）：跑 SuiteCRM 血统的 legacy 修复流程，重建数据库字段元数据与视图缓存，末尾的 VTOOLS2 REBUILD BEGIN./FINISHED SUCCESSFULLY. 两行正是这步落盘视图工具重建的标志输出。
Rebuilding javascript（RepairAndRebuildJavascriptService）：重建压缩合并后的前端 JS 组文件。
Clearing api cache（ClearDirectoryService）：清空 api/cache/ 目录，REST API 下次请求时重建。
Repairing oauth keys permissions（OAuth2RepairPermissionsService）：把 api/configs/private.key、public.key 权限修正为 Web 服务用户可读（实测为 600 www-data:www-data）。

这条命令无参数、无交互、幂等，可以放心随时执行；升级命令内部也会调用它。

七、OAuth2 密钥与客户端：`oauth2:createKeys` / `oauth2:regenerateClientSecret`

MintHCM 的 REST API 走 OAuth2：JWT 用非对称密钥对签发（api/configs/private.key + public.key），前端 SPA 通过预置的 frontend 客户端换取令牌。这两条命令分别对应"换钥匙"与"换门禁码"。

7.1 `oauth2:createKeys` —— 重生成 JWT 密钥对

$ ./MintCLI oauth2:createKeys

Create new OAuth2 keys

======================

writing RSA key
 [OK] Createing new OAuth2 keys was successful.

EXIT=0

效果验证——密钥文件确实被重写了（属主权限自动保持 600 www-data:www-data）：

--- before:
-rw------- 1 www-data www-data 1708 Oct 28 13:12 api/configs/private.key
-rw------- 1 www-data www-data  451 Oct 28 13:12 api/configs/public.key
--- after:
-rw------- 1 www-data www-data 1704 Oct 28 13:55 api/configs/private.key
-rw------- 1 www-data www-data  451 Oct 28 13:55 api/configs/public.key

私钥字节数从 1708 变为 1704，修改时间刷新——新密钥对已生效，此前签发的 access token 全部失效（用户需重新登录，这正是"密钥轮换"的预期行为）。回显中的 Createing 是官方原文拼写，照录。

7.2 `oauth2:regenerateClientSecret` —— 重生成前端客户端密钥

$ ./MintCLI oauth2:regenerateClientSecret

Regenerate Frontend OAuth2 Client Secret

========================================

 [OK] Createing or updating OAuth2 client was successful.

EXIT=0

验证效果：数据库里 frontend 客户端的 secret 是 64 位十六进制哈希（sha256，见 C1 安全段的说明），命令执行后比对 API 端点返回值：

$ mysql -uroot -pq1w2e3r4 minthcm -N -e "select secret from oauth2clients where id='frontend';"
2fe1382f32e35cbc6000e3c0c8263499af319ae960d249d8688d9f0253547671

$ curl -s -X POST http://localhost:8147/api/getInternalFrontendToken
{"client_secret":"2fe1382f32e35cbc6000e3c0c8263499af319ae960d249d8688d9f0253547671"}

两者一致。这就是该命令"低破坏性"的原因：前端 SPA 每次都从 /api/getInternalFrontendToken 运行时拉取客户端密钥，密钥重生成对用户完全无感，无需改任何前端配置。源码还提示了一种兜底场景——若密钥文件缺失，命令会给出 warning 并附上手工生成方法（cd api/configs && openssl genrsa -out private.key 2048 && openssl rsa -in private.key -pubout -out public.key，再补 600 权限与属主）。

八、用户与 SSO：`users:resetOidcBinding`

对接 OIDC 单点登录后，每个用户在首次 SSO 登录时会与 IdP 的 sub 主体声明绑定；IdP 侧重建账号或切换 IdP 后，旧绑定会阻碍登录，这条命令负责解除。help 原文给出了标准用法：

Description:
  Reset the OIDC (SSO) subject binding of one user or of all users

Usage:
  users:resetOidcBinding [options]

Options:
      --user=USER       User name (user_name) whose binding is reset
      --all             Reset the bindings of all users
      --force           Do not ask for confirmation with --all

Help:
  Each user is bound to the OIDC "sub" claim on the first single sign-on login.
  After the account was recreated in the IdP, or after switching to another IdP, reset the binding:
    php MintCLI users:resetOidcBinding --user=jsmith
    php MintCLI users:resetOidcBinding --all

对三种分支逐一实测，注意退出码的差别：

# 分支一：正常用户（未做过 SSO 登录，无绑定）
$ ./MintCLI users:resetOidcBinding --user=admin

 ! [NOTE] admin has no OIDC binding.

EXIT=0

# 分支二：不带参数（--user 与 --all 必须二选一）
$ ./MintCLI users:resetOidcBinding

 [ERROR] Pass exactly one of --user=<user_name> or --all.

EXIT=2

# 分支三：查无此人
$ ./MintCLI users:resetOidcBinding --user=nosuchuser

 [ERROR] User not found: nosuchuser

EXIT=1

--all 会连带二次确认（Reset the OIDC binding of ALL users?），加 --force 才跳过确认；纯本地账号体系下本命令通常停在分支一的 NOTE，无害。

九、后台调度：`cron.php`（非 MintCLI 但同属命令行层）

调度入口不是 MintCLI 而是传统的 cron.php，部署篇第九节已配置系统 crontab，实测机器上的计划任务为：

* * * * * cd /var/www/minthcm/legacy; php -f cron.php > /dev/null 2>&1

手动运行验证（stdout 仅有一条历史遗留的 PHP Notice，进程本身正常退出）：

$ cd /var/www/minthcm/legacy && sudo -u www-data php cron.php
PHP Notice:  Only variables should be passed by reference in /var/www/minthcm/legacy/include/utils.php on line 1224

EXIT=0

连续快速运行会被节流，且提示不打在 stdout 而是写进 legacy/minthcm.log——连续两次手动运行后日志新增：

Wed Oct 28 13:56:20 2026 [2855][1][FATAL] Job runs too frequently, throttled to protect the system.
Wed Oct 28 13:56:34 2026 [2870][1][FATAL] Job runs too frequently, throttled to protect the system.

这正是 config.php cron 段（C1 2.6 节）min_cron_interval => 30（相邻两轮最小间隔秒数）的保护在起作用。排障口诀：cron 是否在干活，看 minthcm.log 的时间戳与调度作业记录，别盯着屏幕输出——计划任务里 stdout 本来就被丢弃，屏幕上永远看不到东西。

十、高频组合场景

场景	命令序列	说明
修改 ES 前缀/连接参数后	改 `legacy/config.php` → `instance:rebuild` → `elasticsearch:reindex`	前缀改了必须紧跟全量重索引，否则列表与搜索指向不存在的索引（C1 实录 3）
reindex 报 `Failed to parse Host URL`	核对 `search.ElasticSearch.host` → 修复 → 重跑	本篇 5.1 节完整实录，退出码 1
批量导入后个别模块搜索缺数据	`elasticsearch:reindexModule <模块>`	秒级单模块刷新，避免全量重建
页面白屏/样式错乱/改了语言包	`instance:rebuild`	幂等安全，四步修复
API 密钥疑似泄露，轮换密钥	`oauth2:createKeys` → `oauth2:regenerateClientSecret`	前者令旧 token 失效，后者对前端无感
切换 IdP 后全员无法 SSO 登录	`users:resetOidcBinding --all --force`	解除全部 `sub` 绑定，下次 SSO 登录自动重建
搭建培训/演示环境	调好一套实例 → `demodata:dump` → 新实例 `install` 时选择灌入	种子数据工作流

十一、小结

MintHCM 的命令行层职责边界清晰：install/upgrade 管生命周期，demodata:* 管种子数据，elasticsearch:* 管搜索索引，instance:rebuild 管缓存与元数据修复，oauth2:* 管 API 凭据，users:resetOidcBinding 管 SSO 绑定，cron.php 管后台调度。全部 10 个管理命令均可在无图形界面的生产服务器上完成运维闭环。理解了每条命令对应的配置层（C1）与部署前提（部署指南），这套 CLI 就是一个可靠的全自动挡。

项目认知与版本选型：《MintHCM 介绍与选型指南》
依赖链安装与初始化实录：《MintHCM Debian 12 安装部署指南（Apache + MariaDB + Elasticsearch 实测）》
配置参数逐项语义与生效验证：《MintHCM 配置参数详解》

MintHCM 常用 CLI 命令详解

MintHCM 常用 CLI 命令详解

一、MintCLI 入口与运行方式

1.1 入口文件与源码结构

1.2 怎么跑

1.3 全局选项

1.4 命令清单：./MintCLI list

二、命令速查表

三、安装与升级：install / upgrade

3.1 install —— 全新安装

3.2 upgrade —— 升级到指定版本

四、演示数据：demodata:dump / demodata:install

4.1 demodata:dump —— 把现有库导出为演示数据种子

4.2 demodata:install —— 向库内灌入演示数据

五、Elasticsearch 索引：elasticsearch:reindex / elasticsearch:reindexModule

5.1 全量重索引 elasticsearch:reindex —— 附一次故障实录

5.2 单模块重索引 elasticsearch:reindexModule

六、实例维护：instance:rebuild

七、OAuth2 密钥与客户端：oauth2:createKeys / oauth2:regenerateClientSecret

7.1 oauth2:createKeys —— 重生成 JWT 密钥对

7.2 oauth2:regenerateClientSecret —— 重生成前端客户端密钥

八、用户与 SSO：users:resetOidcBinding

九、后台调度：cron.php（非 MintCLI 但同属命令行层）

十、高频组合场景

十一、小结

1.4 命令清单：`./MintCLI list`

三、安装与升级：`install` / `upgrade`

3.1 `install` —— 全新安装

3.2 `upgrade` —— 升级到指定版本

四、演示数据：`demodata:dump` / `demodata:install`

4.1 `demodata:dump` —— 把现有库导出为演示数据种子

4.2 `demodata:install` —— 向库内灌入演示数据

五、Elasticsearch 索引：`elasticsearch:reindex` / `elasticsearch:reindexModule`

5.1 全量重索引 `elasticsearch:reindex` —— 附一次故障实录

5.2 单模块重索引 `elasticsearch:reindexModule`

六、实例维护：`instance:rebuild`

七、OAuth2 密钥与客户端：`oauth2:createKeys` / `oauth2:regenerateClientSecret`

7.1 `oauth2:createKeys` —— 重生成 JWT 密钥对

7.2 `oauth2:regenerateClientSecret` —— 重生成前端客户端密钥

八、用户与 SSO：`users:resetOidcBinding`

九、后台调度：`cron.php`（非 MintCLI 但同属命令行层）