不建议在内置类型原型上添加方法，应使用工具函数、命名空间组织、ES模块导入或封装安全包装类；仅在填补标准化API且满足检测、不覆盖、封闭环境三条底线时才可扩展。
不建议直接在内置类型（如 Array、String、Date）的原型上添加方法。看似省事，实则容易引发冲突、破坏 polyfill、干扰第三方库，甚至被未来标准覆盖——比如你写的 Array.prototype.groupBy 可能某天就和原生行为不一致。
用工具函数替代原型污染
把通用逻辑写成独立、无副作用的函数，调用时显式传入数据，语义清晰、可测试、易复用：
- 写成
arrayUnique([1,2,2,3])，而不是[1,2,2,3].unique() - 按功能组织命名空间，例如
Arr.filterFalsy(arr)或Str.capitalize(str) - 配合 ES 模块导入：
import { compact } from './utils/array.js'，支持 tree-shaking，避免无用代码打包
需要链式调用？封装类更安全
若确实追求类似 new SmartArray([1,2,3]).unique().map(x => x * 2) 的体验，应创建包装类，而非修改 Array.prototype：
- 内部持有原生数组（如
this._arr = arr），不侵入全局环境 - 每个方法返回新实例或不可变结果，天然支持链式与函数式风格
- 可自由加入类型校验、缓存、日志等增强能力，TypeScript 类型推导也更友好
极少数必须扩展时，守住三条底线
仅当填补已标准化但运行环境尚未支持的 API（如旧浏览器缺 Array.prototype.at），且同时满足：
立即学习“Java免费学习笔记（深入）”；
- 先检测原生是否存在：
if (!Array.prototype.at) { Array.prototype.at = … } - 不覆盖已有方法，命名严格遵循标准（如不用
groupBy以外的相似名） - 确保运行在完全可控的封闭环境（如无第三方脚本的内部后台），并配有完整单元测试覆盖
真正提升开发效率的，不是让每个数组都“多一个方法”，而是模块边界清晰、类型约束可靠、函数组合自然。
