如果你的团队刚启动一个新项目负责人发来一条消息“我们服务的代号就叫 ⚡️辉 煌 の 马 卡 龙⚡️。”别急着当成玩笑。这种“看起来很有气氛”的名字在真实开发里会变成一串需要反复处理的工程问题Git 仓库路径能不能用中文Maven 的artifactId能不能带特殊符号Docker 镜像标签能不能出现“の”Kubernetes Service 名称和 Prometheus 指标前缀又该怎么处理如果只做内部代号大家口头叫“马卡龙”没有任何问题。但一旦进入代码仓库、构建产物、部署清单、监控采集、日志索引这些环节命名就不是审美问题而是系统标识的规范问题。本文不针对某个具体开源产品因为这里只有“项目标题”没有附带功能清单和源码。我更想借“马卡龙”这个代号把一套从代号到落地的工程化思路讲清楚包括概念、流程、示例、排错和最佳实践。读完你至少能回答一个问题接到一个花哨的项目代号如何以尽量小的成本把它安全地用到 Git、镜像、CI 和配置里。1. 这篇文章真正要解决的问题真实开发里“起名”往往发生在项目开始之前而“起名的代价”会在项目上线之后反复出现。用“马卡龙”作为服务代号第一次遇到麻烦的地方通常不是开会而是git clone。如果仓库路径直接写成中文git clone https://git.example.com/infra/⚡️辉煌の马卡龙⚡️.git这不一定会报错但会在很多工具链里带来不必要的麻烦命令行补全失效、IDEA 控制台编码错乱、自动化脚本解析路径困难、第三方 CI 解析失败。更常见的问题是不同人复制的路径不一样有人用“輝煌”有人用“辉煌”有人去掉空格最终导致“统一命名”需要人工监督。这篇文章想解决的正是“项目代号如何从头脑里的灵感变成一套稳定可用的系统标识”。具体包括几个层面第一命名分层。必须区分“展示名”“技术代号”“内部别名”这三类不能混用。展示名可以用中文可以有氛围感技术代号必须短、小写、稳定方便被机器读取。第二配置落地。代号要进入项目配置、镜像名称、Compose 服务名、CI 环境变量中每一个环节都有各自的字符限制和换行规则。第三自动化校验。让 CI 在合并前检查一次命名让脚本在构建前统一生成 slug比靠评审意见逐条提醒可靠得多。第四团队一致性。当“马卡龙”被翻译成 Macaron、Macaroon、马卡隆三个说法时日志、监控、文档就会自然分裂。需要有一个明确的来源记录。所以这篇文章真正适合的读者不是正在写“hello world”的入门新手而是后端工程师需要在服务启动时配置正确的应用名DevOps / SRE需要为服务和镜像制定命名规范架构师或团队负责人需要在项目启动前定义代号原则任何接到“花哨项目名”却不知道往哪放的技术同学。这一章可以给出一个非常明确的结论命名规范不是束缚创造力的流程而是一种低成本的投资。项目代号可以有趣但落到机器层必须稳定。2. 基础概念与核心原理开始写代码之前先把“项目名”拆开看。一个业务项目实际会同时存在多套名称每套名称服务的对象完全不同。2.1 项目名、服务名、展示名、技术代号项目名 / 业务名面向业务和管理通常出现在立项文档、会议室、PPT 里。例如“马卡龙订单项目”可以随意中文表达。展示名Display Name面向用户或运维界面会出现在页面标题、监控看板、应用管理平台上。可以有空格、中文、品牌符号。技术代号Codename面向代码、文件系统、域名、镜像、配置最理想的是小写英文字母加数字连字符全局稳定例如macaron-order。服务名Service Name面向进程管理、容器网络、服务发现通常受限于系统字符集不能有大写和特殊符号。很多团队只定义一个“项目名”然后让所有系统都用这个中文名。这样短期可以用但长期会有一堆副作用比如application.properties里写了中文注释没问题但把中文直接写进artifactId、镜像标签或 DNS 前缀时就不合适。2.2 slug 与命名规则slug 是指一段适合 URL、文件名、标识符的短文本。一个典型的 slug 规则是只使用小写字母、数字、连字符不能以连字符开头或结尾不使用空格、下划线、中文、日文、星号长度建议控制在 3 到 63 个字符之间。为什么是连字符而不是下划线因为在 DNS 名称、域名、部分服务标识中下划线不是合法字符连字符是更通用的选择。如果希望保持人类可读macaron-order-service比macaron_order_service在命名的可迁移性上更好。2.3 代号如何进入系统层代号进入系统层遵循“从展示名到技术代号再展开”的原则。在源码里写明文配置在容器环境里通过 environment 注入在 CI 里通过变量传给构建任务。环境不同代号含义要一致开发环境叫macaron-order-dev生产环境叫macaron-order-prod不能让一个叫macaron-order另一个叫MacaRonOrder。实际中容易踩坑的是“大小写还原”和“字符集不统一”。Linux 文件名大小写敏感Windows 不敏感Docker 镜像标签只允许小写配置中心键名却经常区分大小写。一不留神就会出现本地能跑、CI 失败、上生产又恢复的情况。2.4 不同场景下的命名格式场景是否可以使用“辉煌的马卡龙”推荐格式示例沟通文档 / 会议可以中文展示名辉煌的马卡龙Git 仓库名不建议直接中文小写英文连字符macaron-orderMaven artifactId不可以带中文和特殊符号小写英文连字符macaron-orderDocker 镜像标签不可以带中文和“の”小写英文连字符macaron-order:latestKubernetes Service不可以带下划线和大写小写英文连字符macaron-order环境变量名不用连字符使用下划线大写字母加下划线APP_CODENAMEmacaron-order日志索引避免中文和特殊符号小写英文下划线或连字符macaron-order看到这张表你会明白为什么说“命名是分布式问题”同一个概念在不同系统里有不同的允许字符没有一个万能命名能同时满足所有场景所以只能靠分层设计。3. 环境准备与前置条件接下来用一个最小示例演示如何把“马卡龙”规范成一个可用代号并落到实际工程文件里。示例不依赖重型框架只是为了说明思路。3.1 操作系统与工具以下步骤在 Linux、macOS、Windows 上都可运行只要安装好以下工具Git用于版本管理和仓库初始化。Python 3用于执行命名规范化脚本。版本请以实际环境为准。Docker可选用于构建和验证镜像标签。如果你想跳过 Docker可以只运行脚本和 CI 配置示例。一个 CI 平台GitHub Actions、GitLab CI、Jenkins 均可。你不需要真的创建流水线本文给出的配置用于理解维度。3.2 示例目录结构为了演示我们创建一个目录命名为macaron-order。这个目录同时模拟一个 Java 微服务项目但不要求你已经安装完整 Java 环境因为这里不运行 Spring Boot。目录大致如下macaron-order/ ├── .github/ │ └── workflows/ │ └── build.yml ├── docker-compose.yml ├── pom.xml ├── normalize_codename.py └── src/ └── main/ └── resources/ └── application.properties步骤的准备目标是先有一个干净的测试目录再把各种命名规则落到具体文件里。如果实在不想建目录只看代码也可以但强烈建议自己敲一遍因为“命名问题”只有亲手处理过一次才记得住。3.3 权限与安全提醒在做任何命名改造前注意不要直接修改已经在生产环境运行的旧服务。如果服务已经在线上承担流量修改服务名、镜像名、环境变量可能影响服务发现、日志采集和监控告警。建议在独立测试环境验证。记录当前配置和资源清单方便回滚。涉及敏感信息数据库地址、密钥不要写进示例代码统一使用环境变量或 secrets 管理。4. 核心流程拆解现在把“从花哨代号到系统可用标识”的流程拆成五步。每一步都有明确目的不需要都写代码但每一步都能直接影响最终结果。4.1 第一步确定技术代号团队讨论出来的“马卡龙”最终要落到一个slug。这一步最怕的是直接凭空发明一个英文名比如把“马卡龙”擅自改成SweetDessert因为团队成员在代码里看到SweetDessert时很难联想到“马卡龙”。更好的做法是先做映射表展示名辉煌的马卡龙技术代号macaron-ordermacaron来自“马卡龙”的英文order代表业务领域。这样至少保持可追溯。如果没有对应英文也可以用拼音缩写或团队约定的短词关键是“唯一且可解释”。4.2 第二步为技术代号建立校验脚本建议把 slug 校验脚本放到仓库根目录。脚本要做三件事检查当前服务名是否满足字符规则把不满足规则的原始代号转换为最接近的合法 slug输出转换后的结果并提示开发者更新文档或配置。这一步的意义在于把“人工讨论命名”变成“自动检查”。团队不用在 code review 时争论“这里能不能用大写”因为脚本会直接给出结果。4.3 第三步把技术代号写入工程配置在 Java 项目中最典型的是pom.xml的artifactId和application.properties的应用名。如果这两个位置不一致就会出现“项目文件叫 macaron-order但日志和监控里显示的是 demo”这样的混乱。同步点通常有两个构建配置使用artifactId作为默认应用名运行时配置通过环境变量注入应用名而不是硬编码。4.4 第四步镜像与容器命名当项目要容器化部署时镜像名、容器名、Compose service 名都应基于同一个技术代号。镜像 tag 至少包含版本号或 commit SHA便于追溯。建议使用${CODENAME}:${SHA}作为 tag 基础格式不要只用一个latest。4.5 第五步在 CI 中统一注入CI 流水线里通常需要读取项目代号来构建镜像、生成部署清单、上报指标。如果你在每个 job 里单独写死macaron-order一旦要改就得改所有文件。更稳的方式是在流水线最上层定义一个全局变量后续 job 都引用它。4.6 这一步如果错了会发生什么很多人以为“命名不一致”不是 Bug但它会变成一种慢性故障。常见表现有日志按服务名过滤只能查到一半监控面板里同一个服务出现三个标签部署系统里出现macaron_order和macaron-order两个环境镜像仓库里堆满无法判断归属的latest镜像。这些问题不会让进程崩溃但会让排查问题的成本翻倍。5. 完整示例与代码实现下面给出一个可以复制运行的最小示例。这里的代码不是某一整套生产项目而是把上一章的流程用文件形式落下来。5.1 规范化脚本 normalize_codename.py文件路径macaron-order/normalize_codename.py#!/usr/bin/env python3 # -*- coding: utf-8 -*- 将项目代号转换为机器可读的技术别名。 核心思路 1. 先将常见中文名显式映射为英文代号 2. 再做 slug 化处理保证输出只包含小写字母、数字、连字符 3. 如果原始名称经过 slug 化后为空则回退到 fallback。 适用场景 - Git 仓库、Maven artifactId、Docker 镜像名、Kubernetes Service 名称的命名检查。 import re import unicodedata # 业务展示名 - 技术代号 的显式映射表 CODENAME_ALIAS { 马卡龙: macaron, 辉煌的马卡龙: macaron-order, 马卡龙用户中心: macaron-user-center, } def to_slug(name: str, fallback: str app) - str: 将任意字符串转换为合法 slug。 # 优先使用映射表避免中文被直接丢弃 if name in CODENAME_ALIAS: name CODENAME_ALIAS[name] # NFKC 归一化全角字符 name unicodedata.normalize(NFKC, name) name name.lower() # 非小写字母、数字统一替换为连字符并去掉首尾连字符 name re.sub(r[^a-z0-9], -, name).strip(-) return name or fallback if __name__ __main__: samples [ 马卡龙, 辉煌的马卡龙, MacaronShop, ⚡️輝煌の馬卡龍⚡️, macaron-order, ] for sample in samples: print(f{sample!r:30} - {to_slug(sample)})这段代码里的关键逻辑是to_slug。它先把全角字符归一化再统一改成小写然后把所有非字母数字内容替换成连字符。对于“马卡龙”这类中文名如果没有显式映射结果会被替换成连字符最终回退到app这显然不是我们想要的所以映射表是必须的。运行方式cd macaron-order python3 normalize_codename.py预期输出马卡龙 - macaron 辉煌的马卡龙 - macaron-order MacaronShop - macaronshop ⚡️輝煌の馬卡龍⚡️ - app macaron-order - macaron-order注意“MacaronShop”会变成macaronshop说明 slug 化不会智能分词。如果希望得到macaron-shop必须提前在映射表里定义或使用更复杂的分词逻辑。这里也提醒我们自动转换只是兜底规范的核心仍是人工定义别名。5.2 Maven 项目配置文件路径macaron-order/pom.xml?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion groupIdcom.example/groupId artifactIdmacaron-order/artifactId version1.0.0-SNAPSHOT/version namemacaron-order/name description辉煌的马卡龙 - 示例服务/description /project这里最容易 项目代号工程化：从“马卡龙”到Git、Docker与CI的命名规范
如果你的团队刚启动一个新项目负责人发来一条消息“我们服务的代号就叫 ⚡️辉 煌 の 马 卡 龙⚡️。”别急着当成玩笑。这种“看起来很有气氛”的名字在真实开发里会变成一串需要反复处理的工程问题Git 仓库路径能不能用中文Maven 的artifactId能不能带特殊符号Docker 镜像标签能不能出现“の”Kubernetes Service 名称和 Prometheus 指标前缀又该怎么处理如果只做内部代号大家口头叫“马卡龙”没有任何问题。但一旦进入代码仓库、构建产物、部署清单、监控采集、日志索引这些环节命名就不是审美问题而是系统标识的规范问题。本文不针对某个具体开源产品因为这里只有“项目标题”没有附带功能清单和源码。我更想借“马卡龙”这个代号把一套从代号到落地的工程化思路讲清楚包括概念、流程、示例、排错和最佳实践。读完你至少能回答一个问题接到一个花哨的项目代号如何以尽量小的成本把它安全地用到 Git、镜像、CI 和配置里。1. 这篇文章真正要解决的问题真实开发里“起名”往往发生在项目开始之前而“起名的代价”会在项目上线之后反复出现。用“马卡龙”作为服务代号第一次遇到麻烦的地方通常不是开会而是git clone。如果仓库路径直接写成中文git clone https://git.example.com/infra/⚡️辉煌の马卡龙⚡️.git这不一定会报错但会在很多工具链里带来不必要的麻烦命令行补全失效、IDEA 控制台编码错乱、自动化脚本解析路径困难、第三方 CI 解析失败。更常见的问题是不同人复制的路径不一样有人用“輝煌”有人用“辉煌”有人去掉空格最终导致“统一命名”需要人工监督。这篇文章想解决的正是“项目代号如何从头脑里的灵感变成一套稳定可用的系统标识”。具体包括几个层面第一命名分层。必须区分“展示名”“技术代号”“内部别名”这三类不能混用。展示名可以用中文可以有氛围感技术代号必须短、小写、稳定方便被机器读取。第二配置落地。代号要进入项目配置、镜像名称、Compose 服务名、CI 环境变量中每一个环节都有各自的字符限制和换行规则。第三自动化校验。让 CI 在合并前检查一次命名让脚本在构建前统一生成 slug比靠评审意见逐条提醒可靠得多。第四团队一致性。当“马卡龙”被翻译成 Macaron、Macaroon、马卡隆三个说法时日志、监控、文档就会自然分裂。需要有一个明确的来源记录。所以这篇文章真正适合的读者不是正在写“hello world”的入门新手而是后端工程师需要在服务启动时配置正确的应用名DevOps / SRE需要为服务和镜像制定命名规范架构师或团队负责人需要在项目启动前定义代号原则任何接到“花哨项目名”却不知道往哪放的技术同学。这一章可以给出一个非常明确的结论命名规范不是束缚创造力的流程而是一种低成本的投资。项目代号可以有趣但落到机器层必须稳定。2. 基础概念与核心原理开始写代码之前先把“项目名”拆开看。一个业务项目实际会同时存在多套名称每套名称服务的对象完全不同。2.1 项目名、服务名、展示名、技术代号项目名 / 业务名面向业务和管理通常出现在立项文档、会议室、PPT 里。例如“马卡龙订单项目”可以随意中文表达。展示名Display Name面向用户或运维界面会出现在页面标题、监控看板、应用管理平台上。可以有空格、中文、品牌符号。技术代号Codename面向代码、文件系统、域名、镜像、配置最理想的是小写英文字母加数字连字符全局稳定例如macaron-order。服务名Service Name面向进程管理、容器网络、服务发现通常受限于系统字符集不能有大写和特殊符号。很多团队只定义一个“项目名”然后让所有系统都用这个中文名。这样短期可以用但长期会有一堆副作用比如application.properties里写了中文注释没问题但把中文直接写进artifactId、镜像标签或 DNS 前缀时就不合适。2.2 slug 与命名规则slug 是指一段适合 URL、文件名、标识符的短文本。一个典型的 slug 规则是只使用小写字母、数字、连字符不能以连字符开头或结尾不使用空格、下划线、中文、日文、星号长度建议控制在 3 到 63 个字符之间。为什么是连字符而不是下划线因为在 DNS 名称、域名、部分服务标识中下划线不是合法字符连字符是更通用的选择。如果希望保持人类可读macaron-order-service比macaron_order_service在命名的可迁移性上更好。2.3 代号如何进入系统层代号进入系统层遵循“从展示名到技术代号再展开”的原则。在源码里写明文配置在容器环境里通过 environment 注入在 CI 里通过变量传给构建任务。环境不同代号含义要一致开发环境叫macaron-order-dev生产环境叫macaron-order-prod不能让一个叫macaron-order另一个叫MacaRonOrder。实际中容易踩坑的是“大小写还原”和“字符集不统一”。Linux 文件名大小写敏感Windows 不敏感Docker 镜像标签只允许小写配置中心键名却经常区分大小写。一不留神就会出现本地能跑、CI 失败、上生产又恢复的情况。2.4 不同场景下的命名格式场景是否可以使用“辉煌的马卡龙”推荐格式示例沟通文档 / 会议可以中文展示名辉煌的马卡龙Git 仓库名不建议直接中文小写英文连字符macaron-orderMaven artifactId不可以带中文和特殊符号小写英文连字符macaron-orderDocker 镜像标签不可以带中文和“の”小写英文连字符macaron-order:latestKubernetes Service不可以带下划线和大写小写英文连字符macaron-order环境变量名不用连字符使用下划线大写字母加下划线APP_CODENAMEmacaron-order日志索引避免中文和特殊符号小写英文下划线或连字符macaron-order看到这张表你会明白为什么说“命名是分布式问题”同一个概念在不同系统里有不同的允许字符没有一个万能命名能同时满足所有场景所以只能靠分层设计。3. 环境准备与前置条件接下来用一个最小示例演示如何把“马卡龙”规范成一个可用代号并落到实际工程文件里。示例不依赖重型框架只是为了说明思路。3.1 操作系统与工具以下步骤在 Linux、macOS、Windows 上都可运行只要安装好以下工具Git用于版本管理和仓库初始化。Python 3用于执行命名规范化脚本。版本请以实际环境为准。Docker可选用于构建和验证镜像标签。如果你想跳过 Docker可以只运行脚本和 CI 配置示例。一个 CI 平台GitHub Actions、GitLab CI、Jenkins 均可。你不需要真的创建流水线本文给出的配置用于理解维度。3.2 示例目录结构为了演示我们创建一个目录命名为macaron-order。这个目录同时模拟一个 Java 微服务项目但不要求你已经安装完整 Java 环境因为这里不运行 Spring Boot。目录大致如下macaron-order/ ├── .github/ │ └── workflows/ │ └── build.yml ├── docker-compose.yml ├── pom.xml ├── normalize_codename.py └── src/ └── main/ └── resources/ └── application.properties步骤的准备目标是先有一个干净的测试目录再把各种命名规则落到具体文件里。如果实在不想建目录只看代码也可以但强烈建议自己敲一遍因为“命名问题”只有亲手处理过一次才记得住。3.3 权限与安全提醒在做任何命名改造前注意不要直接修改已经在生产环境运行的旧服务。如果服务已经在线上承担流量修改服务名、镜像名、环境变量可能影响服务发现、日志采集和监控告警。建议在独立测试环境验证。记录当前配置和资源清单方便回滚。涉及敏感信息数据库地址、密钥不要写进示例代码统一使用环境变量或 secrets 管理。4. 核心流程拆解现在把“从花哨代号到系统可用标识”的流程拆成五步。每一步都有明确目的不需要都写代码但每一步都能直接影响最终结果。4.1 第一步确定技术代号团队讨论出来的“马卡龙”最终要落到一个slug。这一步最怕的是直接凭空发明一个英文名比如把“马卡龙”擅自改成SweetDessert因为团队成员在代码里看到SweetDessert时很难联想到“马卡龙”。更好的做法是先做映射表展示名辉煌的马卡龙技术代号macaron-ordermacaron来自“马卡龙”的英文order代表业务领域。这样至少保持可追溯。如果没有对应英文也可以用拼音缩写或团队约定的短词关键是“唯一且可解释”。4.2 第二步为技术代号建立校验脚本建议把 slug 校验脚本放到仓库根目录。脚本要做三件事检查当前服务名是否满足字符规则把不满足规则的原始代号转换为最接近的合法 slug输出转换后的结果并提示开发者更新文档或配置。这一步的意义在于把“人工讨论命名”变成“自动检查”。团队不用在 code review 时争论“这里能不能用大写”因为脚本会直接给出结果。4.3 第三步把技术代号写入工程配置在 Java 项目中最典型的是pom.xml的artifactId和application.properties的应用名。如果这两个位置不一致就会出现“项目文件叫 macaron-order但日志和监控里显示的是 demo”这样的混乱。同步点通常有两个构建配置使用artifactId作为默认应用名运行时配置通过环境变量注入应用名而不是硬编码。4.4 第四步镜像与容器命名当项目要容器化部署时镜像名、容器名、Compose service 名都应基于同一个技术代号。镜像 tag 至少包含版本号或 commit SHA便于追溯。建议使用${CODENAME}:${SHA}作为 tag 基础格式不要只用一个latest。4.5 第五步在 CI 中统一注入CI 流水线里通常需要读取项目代号来构建镜像、生成部署清单、上报指标。如果你在每个 job 里单独写死macaron-order一旦要改就得改所有文件。更稳的方式是在流水线最上层定义一个全局变量后续 job 都引用它。4.6 这一步如果错了会发生什么很多人以为“命名不一致”不是 Bug但它会变成一种慢性故障。常见表现有日志按服务名过滤只能查到一半监控面板里同一个服务出现三个标签部署系统里出现macaron_order和macaron-order两个环境镜像仓库里堆满无法判断归属的latest镜像。这些问题不会让进程崩溃但会让排查问题的成本翻倍。5. 完整示例与代码实现下面给出一个可以复制运行的最小示例。这里的代码不是某一整套生产项目而是把上一章的流程用文件形式落下来。5.1 规范化脚本 normalize_codename.py文件路径macaron-order/normalize_codename.py#!/usr/bin/env python3 # -*- coding: utf-8 -*- 将项目代号转换为机器可读的技术别名。 核心思路 1. 先将常见中文名显式映射为英文代号 2. 再做 slug 化处理保证输出只包含小写字母、数字、连字符 3. 如果原始名称经过 slug 化后为空则回退到 fallback。 适用场景 - Git 仓库、Maven artifactId、Docker 镜像名、Kubernetes Service 名称的命名检查。 import re import unicodedata # 业务展示名 - 技术代号 的显式映射表 CODENAME_ALIAS { 马卡龙: macaron, 辉煌的马卡龙: macaron-order, 马卡龙用户中心: macaron-user-center, } def to_slug(name: str, fallback: str app) - str: 将任意字符串转换为合法 slug。 # 优先使用映射表避免中文被直接丢弃 if name in CODENAME_ALIAS: name CODENAME_ALIAS[name] # NFKC 归一化全角字符 name unicodedata.normalize(NFKC, name) name name.lower() # 非小写字母、数字统一替换为连字符并去掉首尾连字符 name re.sub(r[^a-z0-9], -, name).strip(-) return name or fallback if __name__ __main__: samples [ 马卡龙, 辉煌的马卡龙, MacaronShop, ⚡️輝煌の馬卡龍⚡️, macaron-order, ] for sample in samples: print(f{sample!r:30} - {to_slug(sample)})这段代码里的关键逻辑是to_slug。它先把全角字符归一化再统一改成小写然后把所有非字母数字内容替换成连字符。对于“马卡龙”这类中文名如果没有显式映射结果会被替换成连字符最终回退到app这显然不是我们想要的所以映射表是必须的。运行方式cd macaron-order python3 normalize_codename.py预期输出马卡龙 - macaron 辉煌的马卡龙 - macaron-order MacaronShop - macaronshop ⚡️輝煌の馬卡龍⚡️ - app macaron-order - macaron-order注意“MacaronShop”会变成macaronshop说明 slug 化不会智能分词。如果希望得到macaron-shop必须提前在映射表里定义或使用更复杂的分词逻辑。这里也提醒我们自动转换只是兜底规范的核心仍是人工定义别名。5.2 Maven 项目配置文件路径macaron-order/pom.xml?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion groupIdcom.example/groupId artifactIdmacaron-order/artifactId version1.0.0-SNAPSHOT/version namemacaron-order/name description辉煌的马卡龙 - 示例服务/description /project这里最容易