iOS Objective-C项目中如何让编译器检测NSDecimalNumber的错误运算符比较

嘿，这个问题我太有共鸣了——在金融类项目里把double换成NSDecimalNumber后，最头疼的就是这类“编译器不报错但逻辑全错”的隐藏bug！结合我之前的实战经验，给你几个靠谱的解决方案：

1. 用编译前脚本强制检查（最快落地） #

你可以在Xcode的项目中添加一个自定义Build Phase脚本，每次编译前自动扫描所有Objective-C文件，一旦发现用标准运算符（>/</>=/<=/==/!=）直接比较NSDecimalNumber对象的代码，就抛出错误并终止编译。

步骤：

• 打开Xcode项目，选中目标 -> Build Phases -> 点击+号 -> 选择New Run Script Phase
• 将脚本内容替换为：

  # 正则匹配NSDecimalNumber对象直接用运算符比较的情况
  MATCH_PATTERN='\bNSDecimalNumber\s*\*\s*\w+\s*([<>]=?|==|!=)\s*\bNSDecimalNumber\s*\*\s*\w+'
  
  # 扫描所有.m和.mm文件
  grep -rn "$MATCH_PATTERN" --include="*.m" --include="*.mm" "${SRCROOT}"
  
  # 如果找到匹配项，抛出错误
  if [ $? -eq 0 ]; then
      echo "❌ Error: 发现NSDecimalNumber对象直接使用标准运算符比较！请改用compare:方法进行值比较。"
      exit 1
  fi
  

这个方法的好处是零学习成本，立刻就能生效，强制团队成员修正所有错误用法。

2. 自定义Clang静态分析规则（最精准） #

如果想要更精准的代码检测（比如排除掉一些特殊场景，或者只针对特定变量），可以自定义Clang静态分析规则。核心思路是通过AST匹配器，找到所有NSDecimalNumber类型的变量使用标准比较运算符的节点，然后触发警告或错误。

大概的实现思路：

• 编写一个Clang插件，使用clang::ast_matchers匹配：
  • 左侧和右侧都是NSDecimalNumber指针类型的二进制运算符表达式（BinaryOperator）
  • 运算符类型是BO_GT/BO_LT/BO_GE/BO_LE/BO_EQ/BO_NE
• 匹配到后，通过DiagnosticsEngine抛出编译警告或错误。

虽然需要一点Clang插件的开发知识，但一旦配置完成，就能在代码编写阶段实时提示错误，比脚本检查更及时。

3. 统一封装比较宏（从根源避免错误） #

为了从一开始就避免团队成员误用标准运算符，可以封装一套专门用于NSDecimalNumber比较的宏，要求所有人必须使用这些宏来做值比较：

#import <Foundation/Foundation.h>

#define DECIMAL_IS_GREATER_THAN(a, b) ([(a) compare:(b)] == NSOrderedDescending)
#define DECIMAL_IS_LESS_THAN(a, b) ([(a) compare:(b)] == NSOrderedAscending)
#define DECIMAL_IS_GREATER_OR_EQUAL(a, b) ([(a) compare:(b)] != NSOrderedAscending)
#define DECIMAL_IS_LESS_OR_EQUAL(a, b) ([(a) compare:(b)] != NSOrderedDescending)
#define DECIMAL_IS_EQUAL(a, b) ([(a) compare:(b)] == NSOrderedSame)
#define DECIMAL_IS_NOT_EQUAL(a, b) ([(a) compare:(b)] != NSOrderedSame)

然后在项目的PCH文件中导入这个宏定义，同时配合上面的脚本检查，确保没有人绕过宏直接用运算符。

关于你之前尝试的方法的补充 #

• Swift扩展重载运算符：Objective-C本身不支持运算符重载，所以Swift中重载的运算符无法在Objective-C中调用，这个方法确实走不通。
• C++分类重载运算符：虽然可以在Objective-C++（.mm文件）中为NSDecimalNumber重载运算符，但这会要求项目中的相关文件都改为.mm格式，而且跨文件调用时容易出现兼容性问题，除非你的项目本来就是全Objective-C++，否则不推荐。

最后，建议先通过脚本检查+宏封装的组合快速解决当前问题，之后再考虑引入静态分析规则做长期的代码质量保障。

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