php安全配置记录和常见错误梳理

 

一般部署完php环境后会进行一些安全设置，除了熟悉各类php漏洞外，还能够经过配置php.ini来加固PHP的运行环境，PHP官方也曾经屡次修改php.ini的默认设置。
下面对php.ini中一些安全相关参数的配置进行说明

register_globals
当register_globals = ON时，PHP不知道变量从何而来，也容易出现一些变量覆盖的问题。所以从最佳实践的角度，强烈建议设置 register_globals = OFF，这也是PHP新版本中的默认设置。

open_basediropen_basedir
能够限制PHP只能操做指定目录下的文件。这在对抗文件包含、目录遍历等攻击时很是有用，应该为此选项设置一个值。
须要注意的是，若是设置的值是一个指定的目录，则须要在目录最后加上一个“/”，不然会被认为是目录的前缀。
open_basedir = /home/web/html/

allow_url_include = Off
为了对抗远程文件包含，请关闭此选项，通常应用也用不到此选项。同时推荐关闭的还有allow_url_fopen。

display_errors = Off
错误回显，通常经常使用于开发模式，可是不少应用在正式环境中也忘记了关闭此选项。错误回显能够暴露出很是多的敏感信息，为攻击者下一步攻击提供便利。推荐关闭此选项。

log_errors = On
在正式环境下用这个就好了，把错误信息记录在日志里。正好能够关闭错误回显。

magic_quotes_gpc = Off
推荐关闭，它并不值得依赖（请参考“注入攻击”一章），已知已经有若干种方法能够绕过它，甚至因为它的存在反而衍生出一些新的安全问题。XSS、SQL注入等漏洞，都应该由应用在正确的地方解决。同时关闭它还能提升性能。

cgi.fix_pathinfo = 0
若PHP以CGI的方式安装，则须要关闭此项，以免出现文件解析问题（请参考“文件上传漏洞”一章）。

session.cookie_httponly = 1  开启HttpOnly

session.cookie_secure = 1
如果全站HTTPS则请开启此项。

sql.safe_mode = Off
PHP的安全模式是否应该开启的争议一直比较大。一方面，它会影响不少函数；另外一方面，它又不停地被黑客们绕过，所以很难取舍。若是是共享环境（好比App Engine），则建议开启safe_mode，能够和disable_functions配合使用；
若是是单独的应用环境，则能够考虑关闭它，更多地依赖于disable_functions控制运行环境安全。

disable_functions =
可以在PHP中禁用函数（如上默认=号后面什么都不配置）。这是把双刃剑，禁用函数可能会为开发带来不便，但禁用的函数太少又可能增长开发写出不安全代码的概率，同时为黑客获取webshell提供便利。
通常来讲，若是是独立的应用环境，则推荐禁用如下函数：
disable_functions = escapeshellarg, escapeshellcmd, exec,passthru, proc_close, proc_get_status, proc_open, proc_nice,proc_terminate, shell_exec, system, ini_restore, popen, dl,disk_free_space, diskfreespace, set_time_limit, tmpfile, fopen,readfile, fpassthru, fsockopen, mail, ini_alter, highlight_file,openlog, show_source, symlink, apache_child_terminate,apache_get_modules, apache_get_version, apache_getenv,apache_note, apache_setenv, parse_ini_file

php 上传大文件主要涉及配置upload_max_filesize和post_max_size两个选项

曾经遇到的问题：
在网站后台上传图片的时候出现一个很是怪的问题，有时候表单提交能够获取到值，有时候就获取不到了，连普通的字段都获取不到了，苦思冥想还没解决，最后问了师傅，
师傅看了说挺奇怪的，而后问我 upload_max_filesize的值改了吗，我说改了啊，师傅也解决不了了。过了一会师傅问 post_max_size改了吗，我说那个和上传不要紧吧，
师傅没理我，我仍是照着本身的想法继续测试，弄了半天仍是不行，最后试了师傅提的意见，成功了，原来上传是和 post_max_size有关系的。
 
问题总结 :
php.ini配置文件中的默认文件上传大小为 2M，默认upload_max_filesize = 2M ，即文件上传的大小为 2M，若是你想上传超过8M的文件，好比 20M，
 
必须设定 upload_max_filesize = 20M。可是光设置upload_max_filesize = 20M仍是没法实现大文件的上传功能，你必须修改 php.ini配置文件中的post_max_size选项，
其表明容许 POST的数据最大字节长度，默认为 8M。若是POST 数据超出限制，那么 $_POST和$_FILES 将会为空。要上传大文件，
你必须设定该选项值大于 upload_max_filesize指令的值，我通常设定upload_max_filesize和 post_max_size值相等。
另外若是启用了内存限制，那么该值应当小于 memory_limit选项的值。
 
文件上传的其余注意事项 :
在上传大文件时，你会有上传速度慢的感受，当超过必定的时间，会报脚本执行超过 30秒的错误，这是由于在php.ini配置文件中 max_execution_time 配置选项在做怪，
其表示每一个脚本最大容许执行时间 (秒) ，0 表示没有限制。你能够适当调整 max_execution_time的值，不推荐设定为0。
********************************************************************************************************
解释：
具体可查看 PHP手册 中的 〔php.ini 核心配置选项说明〕
upload_max_filesize 所上传的文件的最大大小。 
post_max_size       设定 POST 数据所容许的最大大小。
memory_limit        设定了一个脚本所可以申请到的最大内存字节数。

通常来讲：memory_limit > post_max_size > upload_max_filesize
 
upload_max_filesize是限制本次上传的最大值
post_max_size是post数据的最大值， 经过POST提交数据的最大值
通常咱们在php中用的是POST方式上传

=================================================================================
php.ini中记录PHP错误日志的参数：display_errors与log_errors的区别

1）display_errors 
错误回显，通常经常使用语开发模式，可是不少应用在正式环境中也忘记了关闭此选项。错误回显能够暴露出很是多的敏感信息，为攻击者下一步攻击提供便利。推荐关闭此选项。 

display_errors = On 
开启状态下，若出现错误，则报错，出现错误提示。即显示全部错误信息。 

dispaly_errors = Off 
关闭状态下，若出现错误，则提示：服务器错误，可是不会出现错误提示。即关闭全部错误信息

2）log_errors 
在正式环境下用这个就好了，把错误信息记录在日志里。正好能够关闭错误回显。 

log_errors = On    //注意，log_errors设置为On后，那么dispaly_errors就要设置为Off，这两个不能同时打开。

error_log = /Data/logs/php/error.log   //注意，log_errors设置为On时，必需要设置error_log的日志文件路径，而且这个日志文件要能有权限正常写入。

也就是说log_errors = On时，必须指定error_log文件，若是没指定或者指定的文件没有权限写入，那么照样会输出到正常的输出渠道，那么也就使得display_errors 这个指定的Off失效，错误信息仍是打印了出来。

对于PHP开发人员来讲，一旦项目上线后，第一件事就是应该将display_errors选项关闭，以避免由于这些错误所透露的路径、数据库链接、数据表等信息而遭到黑客攻击。 

---------------------------------------------------
通常说来：

测试环境下的php.ini中的错误日志设置：              
error_reporting = E_ALL  
display_errors = On  
html_errors = On  
log_errors = Off  

正式环境下的php.ini中的错误日志设置： 
error_reporting = E_ALL &~ E_NOTICE &~ E_WARNING       //注意这个设置，记得有一次由于这个设置有误，致使了线上一个业务访问出现了nginx 500报错！这个致使了php框架报错！  
display_errors = Off  
log_errors = On  
html_errors = Off  
error_log = /Data/logs/php/error.log 
ignore_repeated_errors = On  
ignore_repeated_source = On  

简单讲解下各个配置的意义：
error_reporting ：设置报告哪些错误  
display_errors ：设置错误是否做为输出的一部分显示  
html_errors ：设置错误信息是否采用html格式  
log_errors ：设置是否记录错误信息  
error_log ：设置错误信息记录的文件  
ignore_repeated_errors ：是否在同一行中重复显示同样的错误信息  
ignore_repeated_source ： 是否重复显示来自同个文件同行代码的错误 

==============================================================================
顺便记录下php的页面总是报时区错误的处理过程：

Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the date_default_timezone_set()
function. In case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected the
timezone 'UTC' for now, but please set date.timezone to select your timezone. in
/usr/local/www/zabbix2/phpinfo.php on line 2
date/time support enabled
"Olson" Timezone Database Version 2013.8
Timezone Database internal
Default timezone UTC

修改php.ini 文件
# vim /usr/local/php/etc/php.ini
........
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = Asia/Shanghai

注意必须把要 php.ini 复制一份到/usr/local/php/lib/下，不然 php 服务默认会到这个 lib 目录下读取 php.ini 文件，没有的话，就是默认时区UTC，这个时区和北京时间相差8小时。
[root@i-gxcmjlge lib]# pwd
/usr/local/php/lib
[root@i-gxcmjlge lib]# ll
total 72
drwxr-xr-x 14 root root 4096 Nov 18 01:11 php
-rw-r--r-- 1 root root 65681 Nov 18 15:01 php.ini

而后重启php服务和nginx/apache服务

除了php.ini文件，还要注意php-fpm.conf配置，以下：

[root@i-v5lmgh7y etc]# cat php-fpm.conf|grep -v "^;"|grep -v "^$"
[global]
pid = run/php-fpm.pid   //pid 设置，默认在安装目录中的 var/run/php-fpm.pid，建议开启
error_log = log/php-fpm.log   //错误日志，默认在安装目录中的 var/log/php-fpm.log
log_level = notice      //错误级别. 可用级别为: alert（必须当即处理）, error（错误状况）, warning（警告状况）, notice（通常重要信息）, debug（调试信息）. 默认: notice.
emergency_restart_threshold = 60
emergency_restart_interval = 60s //表示在emergency_restart_interval所设值内出现SIGSEGV或者SIGBUS错误的php-cgi进程数若是超过 emergency_restart_threshold个，php-fpm就会优雅重启。这两个选项通常保持默认值。
process_control_timeout = 0  //设置子进程接受主进程复用信号的超时时间. 可用单位: s(秒), m(分), h(小时), 或者 d(天) 默认单位: s(秒). 默认值: 0.
daemonize = yes   //后台执行fpm,默认值为yes，若是为了调试能够改成no。在FPM中，可使用不一样的设置来运行多个进程池。 这些设置能够针对每一个进程池单独设置。

[www]
user = nobody     //启动进程的账户
group = nobody    //启动进程的组
listen = 127.0.0.1:9000    //fpm监听端口，即nginx中php处理的地址，通常默认值便可。可用格式为: 'ip:port', 'port', '/path/to/unix/socket'. 每一个进程池都须要设置.
listen.backlog = 1024   //backlog数，，由操做系统决定，-1表示无限制。也能够注释掉此行。
listen.allowed_clients = 127.0.0.1  //（能够不设置此行）容许访问FastCGI进程的IP，若是没有设置或者为空，则容许任何服务器请求链接。设置any为不限制IP，若是要设置其余主机的nginx也能访问这台FPM进程，listen处要设置成本地可被访问的IP。默认值是any。每一个地址是用逗号分隔. 

pm = static   //对于专用服务器，pm能够设置为static，如何控制子进程，选项有static和dynamic。若是选择static，则由pm.max_children指定固定的子进程数。若是选择dynamic，则由下开参数决定：
pm.max_children = 512   //子进程最大数
pm.start_servers = 387  //启动时的进程数
pm.min_spare_servers = 32  //保证空闲进程数最小值，若是空闲进程小于此值，则建立新的子进程
pm.max_spare_servers = 387  //保证空闲进程数最大值，若是空闲进程大于此值，此进行清理
pm.max_requests = 1024  //设置每一个子进程重生以前服务的请求数. 对于可能存在内存泄漏的第三方模块来讲是很是有用的. 若是设置为 '0' 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0
pm.status_path = /status   //fpm状态页面的网址. 若是没有设置, 则没法访问状态页面. 默认值: none. munin监控会使用到

ping.path = /ping   //fpm监控页面的ping网址. 若是没有设置, 则没法访问ping页面. 该页面用于外部检测FPM是否存活而且能够响应请求. 请注意必须以斜线开头 (/)。能够不设置此行。
ping.response = pong  //用于定义ping请求的返回相应. 返回为HTTP 200的text/plain 格式文本. 默认值: pong。能够不设置此行。
 
slowlog = var/log/slow.log   //慢请求的记录日志,配合request_slowlog_timeout使用
request_slowlog_timeout = 0  //设置单个请求的超时停止时间. 该选项可能会对php.ini设置中的'max_execution_time'由于某些特殊缘由没有停止运行的脚本有用. 设置为 '0' 表示 'Off'.当常常出现502错误时能够尝试更改此选项。
request_terminate_timeout = 10s  //当一个请求该设置的超时时间后，就会将对应的PHP调用堆栈信息完整写入到慢日志中. 设置为 '0' 表示 'Off'。能够不设置此行。
rlimit_files = 65535    //设置文件打开描述符的rlimit限制. 默认值: 系统定义值默承认打开句柄是1024，可以使用 ulimit -n查看，ulimit -n 2048修改。
rlimit_core = 0   //设置核心rlimit最大限制值. 可用值: 'unlimited' 、0或者正整数. 默认值: 系统定义值.
catch_workers_output = yes  //重定向运行过程当中的stdout和stderr到主要的错误日志文件中. 若是没有设置, stdout 和 stderr 将会根据FastCGI的规则被重定向到 /dev/null . 默认值: 空.

=================Nginx+Php中限制站点目录防止跨站的配置方案记录（使用open_basedir）===============
方法1）在Nginx配置文件中加入：

fastcgi_param  PHP_VALUE  "open_basedir=$document_root:/tmp/:/proc/";

一般nginx的站点配置文件里用了include fastcgi.conf;，这样的，把这行加在fastcgi.conf里就OK了。
若是某个站点须要单独设置额外的目录，把上面的代码写在include fastcgi.conf;这行下面就OK了，会把fastcgi.conf中的设置覆盖掉。
这种方式的设置须要重启nginx后生效。

方法2）在php.ini中加入

[HOST=www.wangshibo.com]
open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/
[PATH=/home/www/www.wangshibo.com]
open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/

这种方式的设置须要重启php-fpm后生效。

方法3）在网站根目录下建立.user.ini文件，并在该文件中写入下面信息：

open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/

这种方式不须要重启nginx或php-fpm服务。安全起见应当取消掉.user.ini文件的写权限。

php.ini中建议禁止的函数以下：

disable_functions = pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority, eval, popen, passthru, exec, system, shell_exec, proc_open, proc_get_status, chroot, chgrp, chown, ini_alter, ini_restore, dl, pfsockopen, openlog, syslog, readlink, symlink, popepassthru, stream_socket_server, fsocket, chdir

====================php启动后，9000端口没有起来？=====================
问题描述：
php服务安装后，启动php-fpm，启动的时候没有报错。而后ps -ef|grep php没有发现进程起来，lsof -i:9000发现端口也没有起来。
查看日志，发现系统所容许打开的文件数超过了预约设置。

[root@i-v5lmgh7y etc]# /usr/local/php/sbin/php-fpm
[root@i-v5lmgh7y etc]# ps -ef|grep php
[root@i-v5lmgh7y etc]#lsof -i:9000
[root@i-v5lmgh7y etc]#

查看错误日志发现问题：
[root@i-v5lmgh7y log]# tail -f php-fpm.log
[15-Nov-2015 23:53:15] NOTICE: fpm is running, pid 18277
[15-Nov-2015 23:53:15] ERROR: failed to prepare the stderr pipe: Too many open files (24)
[15-Nov-2015 23:53:16] NOTICE: exiting, bye-bye!
[15-Nov-2015 23:53:59] NOTICE: fpm is running, pid 18855
[15-Nov-2015 23:53:59] ERROR: failed to prepare the stderr pipe: Too many open files (24)
[15-Nov-2015 23:54:00] NOTICE: exiting, bye-bye!

发现是系统容许打开的文件数超了预约的设置。须要调大这个值：
[root@i-v5lmgh7y etc]# ulimit -n
1024
[root@i-v5lmgh7y etc]# ulimit -n 65535    //临时解决办法
[root@i-v5lmgh7y etc]# ulimit -n
65535


永久解决办法：
在/etc/security/limits.conf文件底部添加下面四行内容：
[root@i-v5lmgh7y etc]# cat /etc/security/limits.conf
.........
# End of file
* soft nproc unlimited
* hard nproc unlimited
* soft nofile 65535
* hard nofile 65535

而后再次启动php-fpm程序，9000端口就能正常启动了
[root@i-v5lmgh7y etc]# /usr/local/php/sbin/php-fpm
[root@i-v5lmgh7y etc]# ps -ef|grep php
root 21055 1 0 00:12 ? 00:00:00 php-fpm: master process
(/usr/local/php/etc/php-fpm.conf)
nobody 21056 21055 0 00:12 ? 00:00:00 php-fpm: pool www
nobody 21057 21055 0 00:12 ? 00:00:00 php-fpm: pool www

===============下面梳理几个常见的php不恰当配置引起的问题=================

1）request_terminate_timeout的值若是设置为0或者过长的时间，可能会引发file_get_contents的资源问题。
若是访问请求的远程资源反应过慢，php-cgi进程就会一直卡在那里不会超时。虽然php.ini文件里面max_execution_time能够设置PHP脚本的最大执行时间，可是，在php-cgi(php-fpm) 中该参数不会起效。真正可以控制PHP脚本最大执行时间的是php-fpm.conf配置文件中的request_terminate_timeout参数。

request_terminate_timeout默认值为0秒，也就是说，PHP脚本会一直执行下去。这样当全部的php-cgi进程都卡住时，这台Nginx+PHP的WebServer已经没法再处理新的PHP请求了，Nginx 将给用户返回“502 Bad Gateway”。
修改该参数，设置一个PHP脚本最大执行时间是必要的，可是治标不治本。例如改为30s，若是发生访问获取网页内容较慢的状况，这就意味着150个php-cgi进程，每秒钟只能处理5个请求，WebServer一样很难避免”502 Bad Gateway”。

解决办法是request_terminate_timeout设置为10s或者一个合理的值。

2）max_requests参数配置不当，可能会引发间歇性502错误
设置每一个子进程重生以前服务的请求数. 对于可能存在内存泄漏的第三方模块来讲是很是有用的. 
若是设置为0，则一直接受请求，等同于php_fcgi_max_requests环境变量。默认值为 0.
好比：pm.max_requests = 1000  这个配置的意思是，当一个 php-cgi 进程处理的请求数累积到500个后，自动重启该进程。

可是为何要重启进程呢？
通常在项目中，多多少少都会用到一些PHP的第三方库，这些第三方库常常存在内存泄漏问题，若是不按期重启php-cgi进程，势必形成内存使用量不断增加。所以php-fpm做为php-cgi的管理器，提供了这么一项监控功能，对请求达到指定次数的php-cgi进程进行重启，保证内存使用量不增加。正是由于这个机制，在高并发的站点中，常常致使502错误，
目前解决方法是，把这个值尽可能设置大些，尽量减小php-cgi从新SPAWN的次数，同时也能提升整体性能。在实际的生产环境中发现，内存泄漏若是不明显，能够将这个值设置得很是大（好比204800）。要根据本身的实际状况设置这个值（好比咱们线上设置1024），不能盲目地加大。
话说回来，这套机制目的只为保证php-cgi不过度地占用内存，为什么不经过检测内存的方式来处理呢？经过设置进程的峰值内在占用量来重启php-cgi进程，会是更好的一个解决方案。

3）php-fpm的慢日志，debug及异常排查神器
request_slowlog_timeout设置一个超时的参数，slowlog设置慢日志的存放位置

==========php报错日志：PHP Deprecated:Automatically populating $HTTP_RAW_POST_DATA is deprecated=========

以前将线上php服务升级到5.6.x版本后，php-error.log报出错误：
PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated
缘由：
上面的报错意思是“自动变量$HTTP_RAW_POST_DATA已过期（deprecated）”
这个问题和PHP版本有关系,PHP5.6以后的高版本都已废弃了$HTTP_RAW_POST_DATA这个全局变量设置，可使用 php://input 替代 $HTTP_RAW_POST_DATA。
使用always_populate_raw_post_data会致使在填充$HTTP_RAW_POST_DATA时产生E_DEPRECATED 错误。 
设置always_populate_raw_post_data 为-1来体验新的行为，由于这样会强制 $HTTP_RAW_POST_DATA 未定义，因此也不会致使 E_DEPRECATED的错误） 来体验新的行为。

解决方法： 
修改php.ini配置文件：
[root@dev-new-test etc]# vim php.ini
........
; Always populate the $HTTP_RAW_POST_DATA variable.
;always_populate_raw_post_data = On
always_populate_raw_post_data = -1
.......

而后重启php服务便可！

===================phpinfo.php信息泄露漏洞===================

修复:
若无须要能够将一些php的危险函数禁用，打开/etc/php.ini文件，查找到 disable_functions，添加需禁用的如下函数名：
[root@localhost ~]# vim /usr/local/php/etc/php.ini
disable_functions = phpinfo,eval,passthru,exec,system,chroot,scandir,chgrp,chown,shell_exec,proc_open,proc_get_status,ini_alter,ini_alter,ini_restore,dl,pfsockopen,openlog,syslog,readlink,symlink,popepassthru,stream_socket_server,fsocket,fsockopen

expose_php = Off        //隐藏版本号等信息

===============php文件修改后，访问这个文件不会当即更新内容，而是过一下子才回更新=============

缘由是php启动了opcache的模块(php的代码优化和加速模块)！执行php-config命令能够看到php编译安装时跟了--enable-opcache参赛，直接访问以下的php的测试文件：
＃ cat test.php
<?php
phpinfo()
?>

能够看到界面中的“Zend OPcache”模块显示下面两行，表示opcache被启用了！
Opcode Caching  Up and Running
Optimization    Enabled

[root@iZwz96p8207vmn7amyxvw6Z ~]# cat /usr/local/php/etc/php.ini|grep opcache
[opcache]
;opcache.enable=0
;opcache.enable_cli=0
;opcache.memory_consumption=64
;opcache.interned_strings_buffer=4
;opcache.max_accelerated_files=2000
;opcache.max_wasted_percentage=5
;opcache.use_cwd=1
;opcache.validate_timestamps=1
;opcache.revalidate_freq=2
;opcache.revalidate_path=0
;opcache.save_comments=1
;opcache.load_comments=1
;opcache.fast_shutdown=0
;opcache.enable_file_override=0
;opcache.optimization_level=0xffffffff
;opcache.inherited_hack=1
;opcache.dups_fix=0
;opcache.blacklist_filename=
;opcache.max_file_size=0
;opcache.consistency_checks=0
;opcache.force_restart_timeout=180
;opcache.error_log=
;opcache.log_verbosity_level=1
;opcache.preferred_memory_model=
;opcache.protect_memory=0
; opcache.validate_permission=0
; opcache.validate_root=0

[root@iZwz96p8207vmn7amyxvw6Z ~]# /usr/local/php/bin/php -m
........

[Zend Modules]
Zend OPcache
the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured)

这就致使了php文件修改后，在浏览器里访问不会立马生效，须要过30秒左右才生效！由于有opcache缓存的缘由！

解决办法：
在php文件内容的前面添加清理opcache的函数，即opcache_reset();  以下：
[root@iZwz96p8207vmn7amyxvw6Z itime]# cat test.php 
<?php
   opcache_reset();                      //这一行就是清理opcache缓存
   echo  'hjhjhjhjhjh';
?>

这样访问test.php文件，当它的内容更新时，在新的浏览器页面里打开就是更新后的内容了。
若是在老页面里继续访问，第一次刷时清理缓存，第二次刷新就是更新后的内容了！