动词+名词命名能直接暴露行为意图，如deriveuserstatus、validateemailformat；应避免get、process等宽泛动词，选用fetchorderfromdatabase等具体表达；动词须与时态和返回值一致；业务层优先使用领域动词如assesscompatibilityscore。
动词+名词命名直接暴露行为意图
业务代码里最常出现的“看不懂”不是语法问题，而是读完一行 userStatus = calculateStatus(user) 还得跳进 calculateStatus 才知道它到底干了什么。用“动词+名词”组合（比如 deriveUserStatus、validateEmailFormat、enrichUserProfile）能立刻告诉调用方：这个函数在执行一个明确动作，作用对象是啥，结果是什么类型。它不是“计算”，而是“推导”；不是“检查”，而是“校验”；不是“填充”，而是“增强”——每个动词都带语义重量。
避免通用动词导致的语义稀释
像 get、handle、process 这类动词太宽泛，配合名词后依然模糊：getOrder 可能查库、可能走缓存、可能构造假数据；processPayment 是预校验？扣款？发消息？还是三者全包？容易让协作者反复确认上下文。
-
fetchOrderFromDatabase明确 I/O 来源 -
rejectInvalidPayment明确失败路径和判断依据 -
scheduleReminderEmail明确副作用和触发时机
动词越具体，函数边界越清晰，单元测试用例也越容易聚焦。
注意动词时态与返回值一致性
命名中的动词要和实际行为对齐，否则会误导阅读者。常见错位：
-
isUserActive返回bool✅；但写成checkUserActive就暗示可能有副作用（比如记录日志、触发告警），而实际只是纯判断 ❌ -
buildReportUrl返回string✅；若实际是void且内部直接发起 HTTP 请求，就该叫publishReportUrl或submitReportUrl -
normalizePhoneNumber应返回新字符串或修改原对象并返回this；若返回void却不修改入参，就是严重误导
动词一旦选错，后续所有基于命名的推理都会偏航——比没命名更危险。
业务域动词比技术动词更有表达力
技术动词（serialize、map、filter）适合工具层；业务层该用领域语言。例如婚恋 App 中：
- 不用
filterByPreference，改用matchWithUserPreferences - 不用
updateProfile，改用commitProfileEdits（强调用户主动提交动作） - 不用
calculateScore，改用assessCompatibilityScore（带评估意图和领域对象）
这种命名能让产品、测试甚至非技术人员一眼看懂逻辑走向，而不是靠翻代码猜“这个 score 到底算的是匹配度、信用分，还是风控分”。真正难的不是起名，而是把业务规则嚼碎后，挑出那个最准的动词。
