PostGraphile V5 的 Docker 部署实战官方镜像、版本标签与自定义多阶段构建【免费下载链接】crystal Graphiles Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!项目地址: https://gitcode.com/gh_mirrors/cry/crystal导读PostGraphile 是基于 PostgreSQL 自动生成高性能 GraphQL API 的开源服务其 V5 版本当前仓库中 postgraphile/postgraphile/package.json 标注的版本为 5.1.4既提供了开箱即用的官方 Docker 镜像也支持通过自定义 Dockerfile 将你的专属服务容器化。本文围绕 deploying-docker.md 展开系统讲解官方镜像的版本标签规则、自定义多阶段构建的完整 Dockerfile 与 .dockerignore 写法、构建运行命令并结合仓库源码说明 host/port 的传递链路帮助你独立完成 PostGraphile V5 的 Docker 部署。⚠️ 注意原文档特别声明其内容尚未针对 PostGraphile V5 做过完整实测has not yet been tested with PostGraphile V5使用时请谨慎并在遇到问题时向社区反馈。本文沿用这一提醒相关命令以你实际使用的 PostGraphile 版本为准。何时用官方镜像何时自建 Dockerfile官方文档给出了非常清晰的取舍建议官方镜像适合不需要自定义插件、以独立服务方式部署 PostGraphile的场景——即镜像名graphile/postgraphile。你只需要提供数据库连接串拉取镜像即可获得一个完整的 GraphQL API 服务。自定义 Dockerfile适合需要定制化引入自定义插件、定制 preset、扩展 schema、做多阶段瘦身等的场景。此时官方建议使用**多阶段构建multi-stage build**来缩小最终镜像体积。两种路线并不冲突先用官方镜像验证可行性需要深度定制时再切换到自建镜像。官方镜像与版本标签体系官方 Docker 镜像是有版本化标签的理解这套标签规则能避免在生产环境拉到意外版本。原文档给出的完整规则如下标签含义建议graphile/postgraphile:5v5.x.x 系列中最新的稳定版不含 alpha、beta、rc 预发布版本✅推荐使用的标签graphile/postgraphile:v5.6.7-alpha.8示例每个带版本号的 git tag 都会以完全相同的标签名发布镜像精确锁定某个 taggraphile/postgraphile:X-Y、graphile/postgraphile:X-Y-Z每当发布vX.Y.Z不带 alpha/beta/rc的 git tag 时会自动发布对应的大版本对与完整版本镜像自动跟随兼容修复graphile/postgraphile:latest最新的稳定版注意可能包含主版本号跃升如 V4 → V5仅限实验环境graphile/postgraphile:next相当于当前master分支的构建产物预发布 / 激进前沿 / 接近 nightly仅限尝鲜其中:5标签之所以可能偶尔滞后是因为它是上述流程中唯一需要人工维护的步骤每次需要更新时把最新的v5.x.ytag 推送到v5分支git push origin v5.x.y:v5即可触发镜像重建。这一点在你的 CI/CD 无法自动接管时尤其需要注意。为什么有的标签用点、有的标签用横线原文档专门澄清了带点v5.6.7与带横线5-6-7两类标签的差异值得在生产规划时严格区分X和X-Y推荐使用的标签会随时间推移自动更新为兼容的 bug 修复版本X-Y-Z出于完整性发布未来可能包含该特定版本线的 alpha/beta 等预发布版本vX.Y.Z-foo.A这类与 git tag 完全一致的标签只会构建一次不会随项目进展持续更新。需要显式地钉死某个版本时使用它。简单记忆横线标签是会动的浮标点号标签是一次性的锚点。自定义 Dockerfile 前的两个关键点编写自定义 Dockerfile 之前官方文档强调了两个最容易踩坑的要点监听地址PostGraphile CLI 默认监听localhost。容器内默认无法从宿主机/外部直接访问localhost因此通常需要覆盖监听地址例如在 preset 中设置preset.grafserv.host 0.0.0.0。数据库连通性PostGraphile 必须能连上你的 PostgreSQL。要确保 Docker 的网络配置bridge 网络、--network、--add-host等允许容器访问数据库地址。用 .dockerignore 加速构建构建上下文越大镜像构建越慢。官方给出的 .dockerignore 示例可以直接套用# .dockerignore .env .git .github .next .vscode node_modules *Dockerfile* *docker-compose* **/dist **/__tests__要点解读排除.env避免密钥进入构建上下文排除.git、.github、.vscode、.next等与运行时无关的文件排除node_modules依赖统一交给镜像内的yarn install按 lockfile 重建用*Dockerfile*、*docker-compose*排除嵌套子项目中的构建文件排除**/dist若是 Monorepo最终产物由构建阶段单独 COPY与**/__tests__测试目录进一步缩小上下文。多阶段构建 Dockerfile 详解Yarn v4 示例原文档提供了一个基于 Yarn v4、包含三个阶段的 Dockerfile 示例。它演示了全局 ARG 共享 分阶段瘦身 只装生产依赖的经典手法值得完整保留并逐段拆解# Dockerfile # Global args, set before the first FROM, shared by all stages ARG NODE_ENVproduction ARG GRAPHILE_ENVproduction ################################################################################ # Build stage 1 - yarn build FROM node:24-alpine AS builder # Import our shared args ARG NODE_ENV ARG GRAPHILE_ENV # Cache node_modules for as long as possible COPY .yarn/ /app/.yarn/ COPY .yarnrc.yml package.json yarn.lock tsconfig.json /app/ WORKDIR /app/ RUN [corepack, enable] RUN [yarn, install, --immutable] # Copy over the server source code COPY src/ /app/src/ # Finally run the build script RUN [yarn, run, build] ################################################################################ # Build stage 2 - COPY the relevant things (multiple steps) FROM node:24-alpine AS clean # Import our shared args ARG NODE_ENV ARG GRAPHILE_ENV # Copy over selectively just the tings we need, try and avoid the rest COPY --frombuilder /app/.yarnrc.yml /app/package.json /app/yarn.lock /app/ COPY --frombuilder /app/.yarn/releases/ /app/.yarn/releases/ COPY --frombuilder /app/dist/ /app/dist/ ################################################################################ # Build stage FINAL - COPY everything, once, and then do a clean yarn install FROM node:24-alpine # Import our shared args ARG NODE_ENV ARG GRAPHILE_ENV EXPOSE 5678 WORKDIR /app/ # Copy everything from stage 2, its already been filtered COPY --fromclean /app/ /app/ # Install yarn ASAP because its the slowest RUN [corepack, enable] RUN [yarn, workspaces, focus, -A, --production] LABEL descriptionMy PostGraphile-powered server ENV HOST0.0.0.0 ENV NODE_ENV$NODE_ENV ENV GRAPHILE_ENV$GRAPHILE_ENV ENTRYPOINT [yarn, start:production]Stage 1builder完成构建在第一个FROM之前声明ARG NODE_ENV/ARG GRAPHILE_ENV并在每个 stage 内ARG重新导入——这是 Docker 的硬性约束全局 ARG 不会自动进入任何 stage必须逐个声明。先 COPY.yarn/、.yarnrc.yml、package.json、yarn.lock、tsconfig.json再执行yarn install --immutable是为了最大化利用 Docker 层缓存只要 lockfile 不变依赖层就不会重建。corepack enable用于启用 Yarn v4 的 corepack 路由--immutable保证安装结果与 lockfile 严格一致CI 语义更强。最后才 COPYsrc/并执行yarn run build产物落在dist/。Stage 2clean只挑需要的文件这一阶段不再执行任何安装/构建纯粹用COPY --frombuilder从上一阶段选择性拷贝.yarnrc.yml、package.json、yarn.lock、.yarn/releases/Yarn 二进制以及构建产物dist/。原文档注释中的try and avoid the rest正是多阶段瘦身的精髓——早期阶段里的 node_modules、源码、缓存都不会进入最终镜像。Stage 3final只装生产依赖EXPOSE 56785678 正是 PostGraphile 的默认服务端口见下文源码佐证。一次性 COPY clean 阶段的内容然后执行yarn workspaces focus -A --production——这是 Yarn 4 的 workspace 聚焦安装命令只安装生产依赖能显著缩小镜像。通过ENV固化HOST0.0.0.0对应上文必须覆盖 localhost 监听的要点、NODE_ENV与GRAPHILE_ENV并以ENTRYPOINT [yarn, start:production]启动服务。构建与运行在包含上述Dockerfile的项目根目录执行构建docker build -t mypostgraphileproject .该命令使用当前目录即.dockerignore过滤后的上下文构建镜像并打上mypostgraphileproject标签。运行docker run \ --rm \ -it \ -p 5678:5678 \ -e DATABASE_URLpostgres://username:passwordhost:port/db \ mypostgraphileproject各参数的含义原文档逐一说明--rm容器退出时自动删除避免残留-it以交互模式运行并分配 TTY方便查看日志与 Ctrl-C 停止-p 5678:5678把容器内 5678 端口发布到宿主机 5678 端口-e DATABASE_URL…在运行时注入数据库连接串PostGraphile 凭此连接 PostgreSQLmypostgraphileproject要运行的镜像名即上面-t指定的标签。连接宿主机上的 PostgreSQL如果 PostgreSQL 跑在宿主机上、而 PostGraphile 跑在容器里官方文档给出了一个实用技巧使用 Docker 的--add-host参数把宿主机映射为可解析的主机名docker run --add-hosthost.docker.internal:host-gateway ...连接串写作postgres://username:passwordhost.docker.internal/mydb即可连到宿主机的mydb数据库。同时需要确保 PostgreSQL 的listen_address配置正确# ... listen_address localhost,172.17.0.1 port 5432 # ...注意172.17.0.1是 Docker 默认 bridge 网络下宿主机的常见地址且文档提醒在 Docker daemon 启动之后可能需要重启 PostgreSQL让端口正确绑定。从源码看 host/port 的传递路径官方文档中默认监听 localhost、默认端口 5678的说法可以在仓库源码中得到印证postgraphile/postgraphile/src/cli.ts 中CLI 通过 yargs 定义了--connection/-c、--schema/-s、--port/-p、--host/-n、--watch/-w、--subscriptions、--preset/-P、--allow-explain/-e等选项其中--port与--host分别描述为HTTP 服务器监听的端口号与HTTP 服务器绑定的主机在 cli.ts 的 run 函数 中rawPort/rawHost会被写入preset.grafserv!.port/preset.grafserv!.host说明 CLI 参数最终汇入 graphile-config 的 preset 体系在 cli.ts 的监听逻辑 中最终执行server.listen({ host, port: 5678 })——当用户未显式指定端口时默认值正是5678host与port都取自解析后的config.grafserv。在 grafast/grafserv/src/index.ts 中GrafservOptions明确声明了port?: numberPort number to listen on与host?: stringHost to listen on并有graphqlPath通常为/graphql、graphiql、websockets等相邻选项。因此在自定义 preset 中写preset.grafserv.host 0.0.0.0正是修改这条链路的最直接方式。从上述源码结构可以推断只要把host显式设为0.0.0.0容器内的 PostGraphile 就会监听所有网络接口配合-p 5678:5678即可对外提供 GraphQL 服务若省略host则取决于 Node 默认行为与 Docker 网络配置很可能出现容器内能跑、宿主机访问不到的经典问题——这也是官方文档把监听地址列为第一要点的原因。延伸阅读running-postgraphile-in-docker.md完整的本地双容器PostgreSQL PostGraphile编排指南覆盖 Linux/Windows 上的 Docker 安装与 docker-compose 配置running-postgraphile-as-a-library-in-docker.md以 Node.js 库的形式在容器中运行 PostGraphile以获得比 CLI 更大的定制空间postgraphile/postgraphile/src/cli.tsPostGraphile CLI 的完整实现包含全部命令行选项与端口/主机处理逻辑grafast/grafserv/src/index.tsGrafserv 服务层的配置选项类型定义host、port、graphqlPath、websockets 等。部署到生产环境时建议优先使用graphile/postgraphile:5这类自动跟随 bug 修复的横线标签并在需要完全可复现的构建时改用精确的vX.Y.Z-…点号标签自定义镜像务必覆盖监听地址与数据库连通性两个关键点再借助多阶段构建 .dockerignore把镜像体积和构建时间控制在合理范围。【免费下载链接】crystal Graphiles Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!项目地址: https://gitcode.com/gh_mirrors/cry/crystal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PostGraphile V5 的 Docker 部署实战：官方镜像、版本标签与自定义多阶段构建
PostGraphile V5 的 Docker 部署实战官方镜像、版本标签与自定义多阶段构建【免费下载链接】crystal Graphiles Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!项目地址: https://gitcode.com/gh_mirrors/cry/crystal导读PostGraphile 是基于 PostgreSQL 自动生成高性能 GraphQL API 的开源服务其 V5 版本当前仓库中 postgraphile/postgraphile/package.json 标注的版本为 5.1.4既提供了开箱即用的官方 Docker 镜像也支持通过自定义 Dockerfile 将你的专属服务容器化。本文围绕 deploying-docker.md 展开系统讲解官方镜像的版本标签规则、自定义多阶段构建的完整 Dockerfile 与 .dockerignore 写法、构建运行命令并结合仓库源码说明 host/port 的传递链路帮助你独立完成 PostGraphile V5 的 Docker 部署。⚠️ 注意原文档特别声明其内容尚未针对 PostGraphile V5 做过完整实测has not yet been tested with PostGraphile V5使用时请谨慎并在遇到问题时向社区反馈。本文沿用这一提醒相关命令以你实际使用的 PostGraphile 版本为准。何时用官方镜像何时自建 Dockerfile官方文档给出了非常清晰的取舍建议官方镜像适合不需要自定义插件、以独立服务方式部署 PostGraphile的场景——即镜像名graphile/postgraphile。你只需要提供数据库连接串拉取镜像即可获得一个完整的 GraphQL API 服务。自定义 Dockerfile适合需要定制化引入自定义插件、定制 preset、扩展 schema、做多阶段瘦身等的场景。此时官方建议使用**多阶段构建multi-stage build**来缩小最终镜像体积。两种路线并不冲突先用官方镜像验证可行性需要深度定制时再切换到自建镜像。官方镜像与版本标签体系官方 Docker 镜像是有版本化标签的理解这套标签规则能避免在生产环境拉到意外版本。原文档给出的完整规则如下标签含义建议graphile/postgraphile:5v5.x.x 系列中最新的稳定版不含 alpha、beta、rc 预发布版本✅推荐使用的标签graphile/postgraphile:v5.6.7-alpha.8示例每个带版本号的 git tag 都会以完全相同的标签名发布镜像精确锁定某个 taggraphile/postgraphile:X-Y、graphile/postgraphile:X-Y-Z每当发布vX.Y.Z不带 alpha/beta/rc的 git tag 时会自动发布对应的大版本对与完整版本镜像自动跟随兼容修复graphile/postgraphile:latest最新的稳定版注意可能包含主版本号跃升如 V4 → V5仅限实验环境graphile/postgraphile:next相当于当前master分支的构建产物预发布 / 激进前沿 / 接近 nightly仅限尝鲜其中:5标签之所以可能偶尔滞后是因为它是上述流程中唯一需要人工维护的步骤每次需要更新时把最新的v5.x.ytag 推送到v5分支git push origin v5.x.y:v5即可触发镜像重建。这一点在你的 CI/CD 无法自动接管时尤其需要注意。为什么有的标签用点、有的标签用横线原文档专门澄清了带点v5.6.7与带横线5-6-7两类标签的差异值得在生产规划时严格区分X和X-Y推荐使用的标签会随时间推移自动更新为兼容的 bug 修复版本X-Y-Z出于完整性发布未来可能包含该特定版本线的 alpha/beta 等预发布版本vX.Y.Z-foo.A这类与 git tag 完全一致的标签只会构建一次不会随项目进展持续更新。需要显式地钉死某个版本时使用它。简单记忆横线标签是会动的浮标点号标签是一次性的锚点。自定义 Dockerfile 前的两个关键点编写自定义 Dockerfile 之前官方文档强调了两个最容易踩坑的要点监听地址PostGraphile CLI 默认监听localhost。容器内默认无法从宿主机/外部直接访问localhost因此通常需要覆盖监听地址例如在 preset 中设置preset.grafserv.host 0.0.0.0。数据库连通性PostGraphile 必须能连上你的 PostgreSQL。要确保 Docker 的网络配置bridge 网络、--network、--add-host等允许容器访问数据库地址。用 .dockerignore 加速构建构建上下文越大镜像构建越慢。官方给出的 .dockerignore 示例可以直接套用# .dockerignore .env .git .github .next .vscode node_modules *Dockerfile* *docker-compose* **/dist **/__tests__要点解读排除.env避免密钥进入构建上下文排除.git、.github、.vscode、.next等与运行时无关的文件排除node_modules依赖统一交给镜像内的yarn install按 lockfile 重建用*Dockerfile*、*docker-compose*排除嵌套子项目中的构建文件排除**/dist若是 Monorepo最终产物由构建阶段单独 COPY与**/__tests__测试目录进一步缩小上下文。多阶段构建 Dockerfile 详解Yarn v4 示例原文档提供了一个基于 Yarn v4、包含三个阶段的 Dockerfile 示例。它演示了全局 ARG 共享 分阶段瘦身 只装生产依赖的经典手法值得完整保留并逐段拆解# Dockerfile # Global args, set before the first FROM, shared by all stages ARG NODE_ENVproduction ARG GRAPHILE_ENVproduction ################################################################################ # Build stage 1 - yarn build FROM node:24-alpine AS builder # Import our shared args ARG NODE_ENV ARG GRAPHILE_ENV # Cache node_modules for as long as possible COPY .yarn/ /app/.yarn/ COPY .yarnrc.yml package.json yarn.lock tsconfig.json /app/ WORKDIR /app/ RUN [corepack, enable] RUN [yarn, install, --immutable] # Copy over the server source code COPY src/ /app/src/ # Finally run the build script RUN [yarn, run, build] ################################################################################ # Build stage 2 - COPY the relevant things (multiple steps) FROM node:24-alpine AS clean # Import our shared args ARG NODE_ENV ARG GRAPHILE_ENV # Copy over selectively just the tings we need, try and avoid the rest COPY --frombuilder /app/.yarnrc.yml /app/package.json /app/yarn.lock /app/ COPY --frombuilder /app/.yarn/releases/ /app/.yarn/releases/ COPY --frombuilder /app/dist/ /app/dist/ ################################################################################ # Build stage FINAL - COPY everything, once, and then do a clean yarn install FROM node:24-alpine # Import our shared args ARG NODE_ENV ARG GRAPHILE_ENV EXPOSE 5678 WORKDIR /app/ # Copy everything from stage 2, its already been filtered COPY --fromclean /app/ /app/ # Install yarn ASAP because its the slowest RUN [corepack, enable] RUN [yarn, workspaces, focus, -A, --production] LABEL descriptionMy PostGraphile-powered server ENV HOST0.0.0.0 ENV NODE_ENV$NODE_ENV ENV GRAPHILE_ENV$GRAPHILE_ENV ENTRYPOINT [yarn, start:production]Stage 1builder完成构建在第一个FROM之前声明ARG NODE_ENV/ARG GRAPHILE_ENV并在每个 stage 内ARG重新导入——这是 Docker 的硬性约束全局 ARG 不会自动进入任何 stage必须逐个声明。先 COPY.yarn/、.yarnrc.yml、package.json、yarn.lock、tsconfig.json再执行yarn install --immutable是为了最大化利用 Docker 层缓存只要 lockfile 不变依赖层就不会重建。corepack enable用于启用 Yarn v4 的 corepack 路由--immutable保证安装结果与 lockfile 严格一致CI 语义更强。最后才 COPYsrc/并执行yarn run build产物落在dist/。Stage 2clean只挑需要的文件这一阶段不再执行任何安装/构建纯粹用COPY --frombuilder从上一阶段选择性拷贝.yarnrc.yml、package.json、yarn.lock、.yarn/releases/Yarn 二进制以及构建产物dist/。原文档注释中的try and avoid the rest正是多阶段瘦身的精髓——早期阶段里的 node_modules、源码、缓存都不会进入最终镜像。Stage 3final只装生产依赖EXPOSE 56785678 正是 PostGraphile 的默认服务端口见下文源码佐证。一次性 COPY clean 阶段的内容然后执行yarn workspaces focus -A --production——这是 Yarn 4 的 workspace 聚焦安装命令只安装生产依赖能显著缩小镜像。通过ENV固化HOST0.0.0.0对应上文必须覆盖 localhost 监听的要点、NODE_ENV与GRAPHILE_ENV并以ENTRYPOINT [yarn, start:production]启动服务。构建与运行在包含上述Dockerfile的项目根目录执行构建docker build -t mypostgraphileproject .该命令使用当前目录即.dockerignore过滤后的上下文构建镜像并打上mypostgraphileproject标签。运行docker run \ --rm \ -it \ -p 5678:5678 \ -e DATABASE_URLpostgres://username:passwordhost:port/db \ mypostgraphileproject各参数的含义原文档逐一说明--rm容器退出时自动删除避免残留-it以交互模式运行并分配 TTY方便查看日志与 Ctrl-C 停止-p 5678:5678把容器内 5678 端口发布到宿主机 5678 端口-e DATABASE_URL…在运行时注入数据库连接串PostGraphile 凭此连接 PostgreSQLmypostgraphileproject要运行的镜像名即上面-t指定的标签。连接宿主机上的 PostgreSQL如果 PostgreSQL 跑在宿主机上、而 PostGraphile 跑在容器里官方文档给出了一个实用技巧使用 Docker 的--add-host参数把宿主机映射为可解析的主机名docker run --add-hosthost.docker.internal:host-gateway ...连接串写作postgres://username:passwordhost.docker.internal/mydb即可连到宿主机的mydb数据库。同时需要确保 PostgreSQL 的listen_address配置正确# ... listen_address localhost,172.17.0.1 port 5432 # ...注意172.17.0.1是 Docker 默认 bridge 网络下宿主机的常见地址且文档提醒在 Docker daemon 启动之后可能需要重启 PostgreSQL让端口正确绑定。从源码看 host/port 的传递路径官方文档中默认监听 localhost、默认端口 5678的说法可以在仓库源码中得到印证postgraphile/postgraphile/src/cli.ts 中CLI 通过 yargs 定义了--connection/-c、--schema/-s、--port/-p、--host/-n、--watch/-w、--subscriptions、--preset/-P、--allow-explain/-e等选项其中--port与--host分别描述为HTTP 服务器监听的端口号与HTTP 服务器绑定的主机在 cli.ts 的 run 函数 中rawPort/rawHost会被写入preset.grafserv!.port/preset.grafserv!.host说明 CLI 参数最终汇入 graphile-config 的 preset 体系在 cli.ts 的监听逻辑 中最终执行server.listen({ host, port: 5678 })——当用户未显式指定端口时默认值正是5678host与port都取自解析后的config.grafserv。在 grafast/grafserv/src/index.ts 中GrafservOptions明确声明了port?: numberPort number to listen on与host?: stringHost to listen on并有graphqlPath通常为/graphql、graphiql、websockets等相邻选项。因此在自定义 preset 中写preset.grafserv.host 0.0.0.0正是修改这条链路的最直接方式。从上述源码结构可以推断只要把host显式设为0.0.0.0容器内的 PostGraphile 就会监听所有网络接口配合-p 5678:5678即可对外提供 GraphQL 服务若省略host则取决于 Node 默认行为与 Docker 网络配置很可能出现容器内能跑、宿主机访问不到的经典问题——这也是官方文档把监听地址列为第一要点的原因。延伸阅读running-postgraphile-in-docker.md完整的本地双容器PostgreSQL PostGraphile编排指南覆盖 Linux/Windows 上的 Docker 安装与 docker-compose 配置running-postgraphile-as-a-library-in-docker.md以 Node.js 库的形式在容器中运行 PostGraphile以获得比 CLI 更大的定制空间postgraphile/postgraphile/src/cli.tsPostGraphile CLI 的完整实现包含全部命令行选项与端口/主机处理逻辑grafast/grafserv/src/index.tsGrafserv 服务层的配置选项类型定义host、port、graphqlPath、websockets 等。部署到生产环境时建议优先使用graphile/postgraphile:5这类自动跟随 bug 修复的横线标签并在需要完全可复现的构建时改用精确的vX.Y.Z-…点号标签自定义镜像务必覆盖监听地址与数据库连通性两个关键点再借助多阶段构建 .dockerignore把镜像体积和构建时间控制在合理范围。【免费下载链接】crystal Graphiles Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!项目地址: https://gitcode.com/gh_mirrors/cry/crystal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考