为何Meteor的Match模式采用大写命名？遵循何种规范？

你注意到的这个和ESLint new-cap规则的“冲突”，其实是因为Meteor的Match模块里这些大写标识（比如Match.Any、Match.Optional）的定位和普通构造函数完全不同——它们不是需要用new调用的构造器，而是框架预先定义好的特殊匹配器对象/高阶函数。

它们遵循的是一种针对框架核心特殊API的自定义大写命名规范，背后的逻辑大概是这样：

• 首先，这些匹配器是Meteor内部已经实例化好的单例或者封装好的特殊工具，你不需要自己去实例化，直接使用即可。比如Match.Any是一个代表“匹配任意值”的特殊常量对象，用大写命名是为了和普通变量/函数区分开，突出它的全局、不可变、特殊语义属性。
• 其次，对于Match.Optional这类高阶匹配器函数，用首字母大写是为了统一整个Match模块的API风格，让开发者一眼就能识别出这是Match系统下的核心匹配工具，而不是普通的工具函数。

ESLint的new-cap规则（capIsNew: true）是通用JS社区的一种约定，用来区分构造函数（需要new）和普通函数，但Meteor这里是基于自身框架的API设计需求，特意采用了这种大写命名来强化模块API的辨识度和语义性，属于框架自定义的规范，而非违背通用约定，只是适用场景不同而已。

举个简单的使用场景对比：

• 普通构造函数：const date = new Date()（首字母大写，需要new）
• Match匹配器：check(value, Match.Optional(String))（Match.Optional首字母大写，但直接调用，不需要new，因为它是框架提供的特殊匹配生成函数）

所以本质上，这是Meteor为了让Match模块的API更具辨识度、语义更清晰而采用的自定义命名规范，核心是用大写来标识这些属于匹配系统的特殊成员，而非遵循通用的构造函数命名规则。

内容的提问来源于stack exchange，提问作者Racing Tadpole