intval在win7x64和centos上最大值范围不同的问题

一直使用win7x64进行开发，Web服务器用的是php5.5内置的web服务器，
昨天突然发现一个问题，同样的代码，在win7和centos上，结果不同：
var_dump(intval('21474836470'));
在Win7上输出：int 2147483647
在Centos输出：int 30000000000

手册上说：
最大的值取决于操作系统。 32 位系统最大带符号的 integer 范围是 -2147483648 到 2147483647
64 位系统上，最大带符号的 integer 值是 9223372036854775807。

可是的我系统是win7x64的啊，下载的php也验证了下，是64位版本的，
为什么会出现intval是32位的效果？？？
在WIndows下看phpinfo，也可以看到是64位：
PHP Version 5.5.14
System Windows NT 7D494368868AFA1 6.1 build 7601 (Windows 7 Ultimate Edition Service Pack 1) AMD64
Build Date Jun 25 2014 12:37:32
Compiler MSVC11 (Visual C++ 2012)
Architecture x64

回复讨论(解决方案)

这个不仅仅要看操作系统的版本，还要看php的版本，官方发布的PHP版本均为32位

php5.5以上才有64位的，其他均为32位

php5.5以上才有64位的，其他均为32位

我的php就是5.5的64位版本，
另附上如何判断exe是32位还是64位程序，用UE打开exe，在00000100h这一行附近，会有一个值：
"PE..L" (hex code: 504500004C) = 32 bit
or
"PE..d?" (hex code: 504500006486) = 64 bit

没有人知道吗？？？
难道大家都只在win上开发，或只在Linux上开发？

是否需要用 64 位版本进行开发，需要看运行环境而定。
不然你做的项目会因找不到 64 位服务器而流产
另外，64位系统有真假之分：64位系统64位架构 和 64位系统32位架构（在32位系统中称 32位 和 准32位）

再有就是，或与你遇到的问题可能是个 bug（可上bug网站上查查）现在都 5.6.9 了，可能已经修复了呢？

是否需要用 64 位版本进行开发，需要看运行环境而定。
不然你做的项目会因找不到 64 位服务器而流产
另外，64位系统有真假之分：64位系统64位架构 和 64位系统32位架构（在32位系统中称 32位 和 准32位）

再有就是，或与你遇到的问题可能是个 bug（可上bug网站上查查）现在都 5.6.9 了，可能已经修复了呢？

感谢回复，去https://bugs.php.com/ 搜索了一下，没找到相关bug资料，
另外，又去Windows2008R2企业版上测试了一下，也是同样最大只支持：2147483647

看来后续要尽量迁移到Centos上开发了，避免这种环境不一致的问题

另外，我提的问题，有个地方写错了，可是不能编辑，应该问题是：
var_dump(intval('30000000000'));
在Win7上输出：int 2147483647
在Centos输出：int 30000000000

去提了个bug，回复说这不是bug，
Windows版本的php只是测试版本，不完全，
https://bugs.php.com/bug.php?id=69704

其实即便是支持 64位整型数，那依然还是存在隐患的，如果你的运算结果超过了 64位 整型数了呢？
php 提供有高精度数的运算函数库，并不受机器影响，上亿位（不是上亿，才10位）的数照样能计算出来

其实即便是支持 64位整型数，那依然还是存在隐患的，如果你的运算结果超过了 64位 整型数了呢？
php 提供有高精度数的运算函数库，并不受机器影响，上亿位（不是上亿，才10位）的数照样能计算出来

现在的业务场景是用户表的自增id，已经超过了32位有效值范围，导致开发时出错，线上正常，
64位的有效值范围，估计至少得10年以后，甚至我能不能看到那一天也不一定，哈哈

如果是自增id，那么 MySQL 提供有 BIGINT 本身就是 64位 整型
在 php 当做字符串处理就可以了，自增id 只是个标识，并不参与数学运算

如果是自增id，那么 MySQL 提供有 BIGINT 本身就是 64位 整型
在 php 当做字符串处理就可以了，自增id 只是个标识，并不参与数学运算

是的，之前处理是把字符串用intval转换为数字后，参与sql查询，
发现有这个问题后，
改用正则 ^/d+$ 来判断是否数字，再参与sql查询

在你写的 sql 指令中 数字 不用引号括起的吗？
虽然 aaa=123 和 aaa='123' 是一样的，但后者远比前者安全

在你写的 sql 指令中 数字 不用引号括起的吗？
虽然 aaa=123 和 aaa='123' 是一样的，但后者远比前者安全

嗯，我这边sql不是拼接的，是类似 where id=? 这种传参方案，得到的sql是有引号的