PHP给我带来了更方便的编程，但是我们在使用时以会遇到问题，这里就谈谈PHP上传大文件的小问题吧。由于涉及到本地和服务器两方面的安全问题，所以基于input type="file"形式的页面文件上传一直处于一个很尴尬的位置。一方面，用户不希望隐私泄露，所以浏览器无法对用户在上传时选择的文件做有效的判断。另一方面，为了服务器端的安全，减轻传输负担，系统又希望能在用户开始上传之前就将非法的文件拒之门外。
一来一去，基于原始input方式的上传，成为网络存储网站避之唯恐不及的遗留性问题，也造就了现在千奇百怪的插件、上传客户端。input方式的上传就如此之差么？当然不是。上传文件不大的时候，它还是非常简单可靠的，在PHP中，我们只需要一个复合型表单。
- <form enctype="multipart/form-data" action="__URL__" method="POST">
- 一个输入框
- <input name="userfile" type="file" />
- 和服务器端的一行代码
- move_uploaded_file($_FILES['userfile']['tmp_name'], '/var/www/uploads/'. basename($_FILES['userfile']['name']));
就可以实现整个上传过程。但随文件增大，表单上传的不足就会暴露出来。尤其是我们想取得最基本的文件大小来阻止PHP上传大文件这一简单的想法，也变得如此困难。以下一一道来：通过MAX_FILE_SIZ。我们经常会在手册里读到:
#T#MAX_FILE_SIZE 隐藏字段（单位为字节）必须放在文件输入字段之前，其值为接收文件的***尺寸。这是对浏览器的一个建议，PHP 也会检查此项。在浏览器端可以简单绕过此设置，因此不要指望用此特性来阻挡大文件。实际上，PHP 设置中的上传文件***值是不会失效的。但是***还是在表单中加上此项目，因为它可以避免用户在花时间等待上传大文件之后才发现文件过大上传失败的麻烦。
显然PHP的开发者们也考虑到了PHP上传大文件的问题，但就像手册所说，MAX_FILE_SIZE只是对浏览器的一个建议，事实上目前为止所有主流的浏览器并没有采纳这个建议，所以采用MAX_FILE_SIZE约束文件大小形同摆设，不可行。
通过服务器端
MAX_FILE_SIZE既然无效，那么用户可以将文件上传到服务器，服务器端通过$_FILES['userfile']['size']判断用户上传的文件大小，然后决定是否接受上传并返回信息。暂且排除服务器的负荷以及可能存在的恶意破坏行为，这种解决方案听起来无非是浪费一部分带宽，也能对用户上传文件作出约束。但这也是不可行的，PHP的文件上传受到php.ini以下这些设置的影响:
- post_max_size
- upload_max_filesize
- max_execution_time
- memory_limit
虽然设置方法在手册中都有比较详细的说明，之所以仍然说此方法不可行，是因为php执行脚本在超过memory_limit时，该次的POST数据会全部丢失并且不会报错！试想用户填写了一个超长的表单，并伴随一个超过memory_limit的文件一起上传，经过了漫长的等待时间之后发现等来的又是一张干干净净的空白表单，那是何等印象深刻的用户体验啊。更何况数十M的服务器流量仅仅用来检测文件大小，是现在的网络环境不允许的。
