docs/docs/cn/nocobase-cli/cli-design/nb-proxy-design-intent.md
nb proxy 的设计意图nb proxy 的目的，是把原本比较复杂的入口层流程，用一组更简单、更稳定的命令提供给用户。
如果只聊最核心的流程，先记住这 3 条命令就够了：
nb proxy nginx use docker
nb proxy nginx generate --env test2 --host c.local.nocobase.com
nb proxy nginx reload
大多数场景下，你用 nb proxy 做的事，本质上就是这 3 步：
use 选定当前 provider 的运行方式generate 按 env 和域名生成入口配置reload 让配置生效如果你用的是 Caddy，把命令里的 nginx 换成 caddy 就行。
use local 和 use docker 也可以直接这样记：
use localuse docker这也是 nb proxy 这一层最想提供的体验：你不需要先钻进 Nginx 或 Caddy 的配置细节里，先按固定流程把入口接起来就行。
因为 nb proxy 解决的问题其实很收敛：给应用接一个稳定的对外访问入口。
如果你已经看过 生产环境部署概述，可以把它和 nb app autostart 这样分开记：
nb app autostart 管的是“机器重启后，应用怎么恢复运行”nb proxy 管的是“应用怎么通过 Nginx 或 Caddy 稳定对外提供访问”所以在最常见的部署流程里，nb proxy 并不需要一大串心智。多数时候就是：
够了。
useuse 解决的是“当前准备按哪种方式管理代理”。
比如：
nb proxy nginx use dockernb proxy nginx use local最简单的判断方式就是：
use localuse docker你也可以把它理解成先选好当前 provider 的默认运行方式。后面 start、reload、status 这些命令，就按这套方式去工作。
generategenerate 解决的是“按当前 env，把入口配置渲染出来”。
比如：
nb proxy nginx generate --env test2 --host c.local.nocobase.com
这一步会把 env 里的信息和入口层需要的参数拼起来，生成一份可用的代理配置。这里最关键的输入通常就是：
--env：要暴露哪个 CLI 托管 env--host：要绑定到哪个域名也就是说，generate 管的是配置产物，不是进程状态。
reloadreload 解决的是“让刚生成的配置真正生效”。
nb proxy nginx reload
这样拆开有一个直接好处：配置生成和进程动作不会混在一起。你改了域名、端口或者公开路径时，先重新生成，再决定让它生效，整个过程会更清楚。
use → generate → reload因为这 3 步刚好对应了入口层最稳定的 3 个动作：
如果把这些步骤都塞进一个黑盒命令里，表面上看命令变少了，但一旦出问题，你很难判断到底是 driver 选错了、配置没生成对，还是代理还没 reload。
现在这样拆开之后，排查路径也会更直：
use 不对，就切 drivergenerate 不对，就重生成配置reloadnb proxy 的优势，不只是统一 Nginx 和 Caddy 的命令形式，更重要的是把入口层的高频动作做成可组合流程。
比如你可以直接从代理入口出发：
nb proxy nginx generate --env test2 --reload
也可以从应用配置出发：
nb env update --env test2 --app-port 13000 --proxy-generate --proxy-reload
这两个例子对应的是两种很常见的起点：
generate --reload--proxy-generate --proxy-reload不过最后都会落到同一套稳定流程里：更新配置，生成入口，让代理生效。
nb proxy因为 nb proxy 想统一掉的，不是某一个 Nginx 配置文件，而是入口层的常见动作。
你真正关心的通常不是：
你更关心的是：
nb proxy 就是把这些动作收敛成同一套 CLI 入口。这样你先记住核心流程，就已经能覆盖大多数场景。只有当你要继续排查细节，或者需要特殊配置时，再往下看 provider 自己的页面就行。
nb proxy 最核心的使用心智，就是 use → generate → reload