php整型减法直接用-运算符，高效且无额外开销；需校验输入类型，避免隐式转换风险，溢出时转float，极端场景用bcsub()配合严格校验。
PHP整型减法直接用 - 运算符，无需特殊函数
PHP里两个整型相减，就是写 $a - $b，底层走的是 Zend VM 的整数减法指令，快、稳、没封装损耗。别去找 bcsub() 或 gmp_sub() —— 那是为超大数或高精度准备的，普通 int 用它们反而引入类型转换开销和依赖。
- 只要两个操作数都是整型（
is_int($a) && is_int($b)为true），结果就是整型，溢出时会自动转为float（如PHP_INT_MAX + 1） - 如果其中一个是字符串（比如
"123"），PHP 会隐式转换：先尝试转整型，失败则为0；但这种松散转换容易埋坑，比如"123abc" - 10得113，而"abc123" - 10得-10 - 浮点数参与运算（如
5 - 3.0）结果是float，哪怕值是整数，后续做数组键或switch时可能意外触发类型比较逻辑
注意 PHP_INT_MIN 和溢出边界
PHP 整型有符号，32 位系统上限是 2147483647，下限是 -2147483648。减法可能触碰下限，比如 PHP_INT_MIN - 1 不报错，但结果是 float 类型的正数（因补码溢出后被解释为无符号再转 float）。
- 检查是否溢出？别手动算边界，用
filter_var($result, FILTER_VALIDATE_INT)可验证结果是否仍为有效整型 - 真要处理极端场景（如金融计算），一开始就用
string存数字，配合bcsub()，并确保所有输入都经ctype_digit()或正则校验 -
PHP_INT_SIZE === 8时，64 位整型范围更大，但跨平台部署时不能假设这点，尤其在容器或云函数里运行环境可能不一致
从用户输入拿到整数再相减，必须过滤和校验
前端传来的 $_GET['a'] 看似是数字，实际是字符串，且可能被篡改。直接 $_GET['a'] - $_GET['b'] 是危险的。
- 用
filter_input(INPUT_GET, 'a', FILTER_VALIDATE_INT)，它返回false而非0当校验失败，能区分 “0” 和 “非法输入” - 别用
(int)强转：(int)"123abc"→123，(int)"0x1A"→0（十六进制不识别），而filter_validate_int对十六进制、科学计数法等一律拒绝 - 若允许负数，
FILTER_VALIDATE_INT默认支持；若只接受正整数，加选项['options' => ['min_range' => 0]]
性能差异微乎其微，但可读性和一致性更重要
在常规业务中，$a - $b、intval($a) - intval($b)、filter_var($a, FILTER_VALIDATE_INT) - filter_var($b, FILTER_VALIDATE_INT) 三者执行时间差不到 0.01ms。瓶颈从来不在这里。
立即学习“PHP免费学习笔记（深入）”；
- 真正拖慢的是没校验导致后续逻辑分支爆炸，比如减完去查数据库，结果
$id = "admin'--"被转成0，查出一堆不该查的数据 - 团队协作时，统一用
filter_input()处理外部输入，比每个人各自(int)或intval()更可靠——后者对空字符串、null、布尔值的转换行为不直观 - 测试时记得覆盖边界值：
0、PHP_INT_MAX、PHP_INT_MIN、空字符串、含空格字符串（如" 42 "）、小数字符串（如"3.14"）
整型减法本身没玄机，难的是怎么让输入干净、边界可控、错误可感知。写完 $a - $b 后多看一眼来源，比琢磨运算符优先级实在得多。
