兄弟，你遇到的这个CastError我之前帮好几个开发者排查过，本质上就是用数字类型存手机号踩了MongoDB的典型坑——咱们先把这个问题掰透，再聊存查的全套最佳实践：

为什么用Number类型存手机号绝对是坑？ #

• 前导零丢失：很多国家/地区的本地手机号会带前导零（比如某些欧洲国家的号码），存成Number类型后，前导零会被自动丢弃，直接导致数据失真
• 精度丢失：JavaScript的Number类型安全范围是2^53-1，超过16位的数字就会出现精度丢失，存进去的手机号再取出来就不是原来的数了；就算是11位的国内手机号，虽然没超范围，但用数字存完全没必要，还埋了类型不匹配的雷
• 类型匹配问题：你遇到的CastError，大概率是查询时传入的是字符串格式的手机号，MongoDB试图强制转成Number类型匹配，但类型转换的校验非常严格，稍有不慎就报错

字符串类型才是手机号的最优解 #

用字符串存手机号几乎能解决所有数字类型带来的问题：

• 完全保留原始格式，不管是前导零、国际区号还是用户输入的分隔符（当然建议统一格式后再存）
• 没有精度限制，任何长度的合法手机号都能完整存储
• 查询时类型匹配更直接，不用做额外的类型转换，从根源上避免CastError

存储的最佳实践 #

• 统一标准格式：存之前先把手机号转成无冗余的标准格式，比如去掉所有非数字字符（空格、-、()这些），或者统一使用E.164标准（比如+86138xxxxxxx），这样后续查询不用处理各种格式的差异
• 加查询索引：如果经常要根据手机号查询，给phone字段加单字段索引：

  db.employees.createIndex({ phone: 1 })
  

  能大幅提升精确查询和前缀模糊查询的速度
• Schema层校验：用Mongoose的话，给phone字段加格式校验，确保存进去的都是合法手机号，比如：

  const employeeSchema = new mongoose.Schema({
    phone: {
      type: String,
      required: true,
      match: /^\+?[1-9]\d{1,14}$/ // 符合E.164标准的正则
    }
  })
  

查询的最佳实践 #

• 提前处理查询参数：用户输入的手机号可能带各种格式（比如138-1234-5678、(138)12345678），先在代码层把它转成和存储格式一致的字符串（比如去掉所有非数字，加上国际区号），再执行查询
• 精确查询直接用等于匹配：

  db.employees.find({ phone: "13812345678" })
  

  简单高效，还能用上索引
• 模糊查询优先前缀匹配：如果要支持“搜开头几位”的需求，用前缀正则/^138/，MongoDB能用上索引；如果是中间或后缀匹配，索引就失效了，数据量大的话可以考虑文本索引，但一般前缀匹配足够覆盖大部分业务场景

最后给你的落地建议 #

1. 把Schema里的phone字段类型从Number改成String
2. 如果你已经有存量的数字类型手机号，批量转成字符串：

   db.employees.updateMany(
     { phone: { $type: "number" } },
     [ { $set: { phone: { $toString: "$phone" } } } ]
   )
   

3. 调整查询逻辑，先把前端传入的查询参数处理成标准字符串再查询，之后就再也不会遇到那个烦人的CastError了