register_shutdown_function()在CGI环境下失效问题求助

Hey there! I totally get why this is confusing—you’ve got two environments where the same code behaves differently, and it all boils down to how PHP’s CGI vs FPM modes handle errors at different stages. Let’s break this down and fix it.

Why This Happens #

First, let’s clarify the key difference between your two setups:

• FPM Mode (PHP 7.0): When a script has a syntax error, FPM’s error handling pipeline still allows the shutdown functions you registered to run. This is because FPM manages process execution differently, funneling even compile-time errors (like syntax issues) through the runtime error flow that triggers register_shutdown_function.
• CGI Mode (PHP 5.6): Syntax errors are caught before your script even starts executing. Since register_shutdown_function is registered during script runtime, it never gets a chance to run—PHP bails out immediately and outputs the raw Parse error message directly to the client.

Solutions to Fix the CGI Mode Issue #

1. Use Web Server-Level Error Pages (Recommended) #

The most reliable way to handle this across both environments is to configure your web server (Nginx, Apache, etc.) to serve your HTTP0.html whenever a 500 Internal Server Error occurs. This bypasses PHP’s error output entirely and gives you a consistent error page.

Example for Nginx:

Add this to your server block configuration:

error_page 500 /HTTP0.html;
location = /HTTP0.html {
    root /path/to/your/html/files;
    internal; # Only allow internal requests (not direct user access)
}

Example for Apache:

Add this to your .htaccess or virtual host config:

ErrorDocument 500 /HTTP0.html

2. Adjust PHP CGI Configuration to Hide Raw Errors #

To make sure PHP CGI returns a proper 500 status code instead of dumping the Parse error message, update your php.ini settings:

display_errors = Off
log_errors = On
error_reporting = E_ALL

This will:

• Turn off direct error output to the client
• Log all errors (including syntax ones) to your PHP error log for debugging
• Make the web server trigger the 500 error page you configured earlier

3. Proactive: Simplify Entry Scripts #

If you want to minimize this scenario, keep your main entry script as lightweight as possible—move most of your code into included files. While this won’t eliminate syntax errors entirely, it means that if an included file has a syntax error, your main script might still run long enough to register the shutdown function (though this isn’t guaranteed for all cases).

Final Notes #

The core issue is that CGI mode can’t trigger runtime shutdown functions for compile-time syntax errors. Web server-level error handling is the most robust fix here because it works regardless of PHP’s execution mode, giving you a consistent user experience across both of your servers.

内容的提问来源于stack exchange，提问作者Jean-Philippe Jurnet