一、场景
领导：小A同学，我们要做一个样本上传进行分析的功能，你看下是否使用base64编码加进去，这样客户端的同学就不需要用form-data方式来上传了，直接使用json格式就可以上报，可以让格式上报统一。
小A：好的，领导，马上搞定！
咋看上面的对话没啥问题，很多公司团队内部为了一些标准化的问题，都会进行一些技术选型问题，但是噩梦也就从这个对话开始，功能实现当然都是很简单的，先来看简单流程图：
本身的流程是一个很简单的文件转换成base64上传，再服务端decode保存，在开发联调过程中没有问题，非常完美的走下去了。
二、问题来了
突然有一天终端同学误操作将一个37M文件上传，nginx与php-fpm文件上传限制均为（60M），但是在界面出现500错误，进入docker 日志查看有一条数据：
Allowed memory size of 8388608 bytes exhausted (tried to allocate 1298358 bytes)
玩php的基本都知道这是啥意思，就是代码运行过程中使用内存超过 我们php.ini设置的memory_limit 的值，然后就屁颠屁颠进入php.ini找参数配置，很快找到：
memory_limit=128M
然后就转念一想，不应该出现这个问题，我们知道，php的内部变量使用cow（写时复制）机制来实现，那么内存申请只有在变量赋值变更才会进行
三、测验
接下来我们单独写一个程序来进行测试，将一个4.89M文件进行base64_encode 编码 与base64_decode解码，查看各自占用内存以及过程中占用峰值内存
<?php
$mid = memory_get_usage();
$apk_content = file_get_contents(__DIR__ . '/4bc1c8a05b8505662be778b6dad23b55.apk');
var_dump('文件加载到内存：' . round((memory_get_usage() - $mid) / 1024 / 1024, 2) . 'M');
var_dump('过程中峰值使用的内存：' . round(memory_get_peak_usage() / 1024 / 1024, 2) . 'M');
unset($mid);
$mid = memory_get_usage();
$base64_encode = base64_encode($apk_content);unset($apk_content);
var_dump('base64_encode占用内存：' . round((memory_get_usage() - $mid) / 1024 / 1024, 2) . 'M');
var_dump('过程中峰值使用的内存：' . round(memory_get_peak_usage() / 1024 / 1024, 2) . 'M');
unset($mid);
$mid = memory_get_usage();
base64_decode($base64_encode);
var_dump('base64_decode占用内存：' . round((memory_get_usage() - $mid) / 1024 / 1024, 2) . 'M');
var_dump('过程中峰值使用的内存：' . round(memory_get_peak_usage() / 1024 / 1024, 2) . 'M');
unset($mid); 
