fgetcsv 和 fputcsv 在 PHP 8.4 中核心逻辑未变，但严格类型检查更严、编码与缓冲区处理要求更高，需注意文件打开模式、BOM 添加、数组索引转换及资源安全释放。
fgetcsv 和 fputcsv 在 PHP 8.4 里没变，还是最稳的选择——别被新版本吓住，核心逻辑和 PHP 5.6 时代一模一样，只是默认启用 strict_types=1 后，类型不匹配会直接报 TypeError，这点必须提前防住。
导入 CSV：fgetcsv 读取时为什么总丢数据或报错？
常见现象是某行突然为空、中文变问号、字段错位，甚至 fgetcsv() 返回 false 却没报错。根本原因不是函数坏了，而是文件打开方式、编码、缓冲区三者没对齐。
- 必须用
fopen($file, 'r')，不能用'rb'（二进制模式会干扰fgetcsv内部的换行符识别） - 如果源文件是 GBK/GB2312，
fgetcsv读出来就是乱码字节，得在读取后立刻用mb_convert_encoding($row, 'UTF-8', 'GBK')转，不能等入库再转 - 缓冲区长度参数（第二个参数）建议设为
0或足够大（如8192），PHP 8.4 对过小值更敏感，设100可能截断长字段 - 每行返回的是索引数组，但若 CSV 有空行或全空字段，
fgetcsv仍返回数组（含空字符串），要用array_filter($row, 'strlen')判断是否真有数据
导出 CSV：fputcsv 写入浏览器时 Excel 打开全是乱码？
这不是 PHP 8.4 的锅，是 Excel 默认不认纯 UTF-8 —— 它看到没 BOM 就当 ANSI 处理。哪怕你 header 里写了 charset=utf-8，Excel 也假装看不见。
- 写入前第一件事：用
fwrite($fp, "\xEF\xBB\xBF")手动加 UTF-8 BOM，fputcsv不会帮你干这个 - 表头和数据必须同构：如果用
PDO::FETCH_ASSOC查数据库，得先用array_values($row)转成数字索引，否则fputcsv会把键名当字符串写进去 - 导出到浏览器必须用
fopen('php://output', 'w')，不能写临时文件再readfile()，后者容易触发输出缓冲未清导致下载损坏 - 脚本末尾加
exit;，PHP 8.4 的严格模式下，后续无意输出（比如调试var_dump残留）会直接让 CSV 文件头失效
PHP 8.4 特有坑：类型声明和资源管理更较真了
PHP 8.4 默认开启严格类型检查，且 fclose() 失败会抛 ValueError（以前只是警告）。这意味着以前能蒙混过关的代码，现在直接崩。
立即学习“PHP免费学习笔记（深入）”；
-
fopen返回可能是false，但如果你声明了返回类型resource，PHP 8.4 会直接 TypeError，务必先判空：if (!$fp = fopen(...)) { throw new RuntimeException('无法打开文件'); } -
fgetcsv第二个参数（长度）在 PHP 8.4 中不允许传null或字符串，必须是 int，传'0'会报错 -
fclose建议包在finally块里，或用try/finally确保执行，否则资源泄漏在 CLI 模式下更容易暴露 - 别用
mysql_*函数（早废弃），也别用mysqli_fetch_assoc直接喂给fputcsv—— 它返回关联数组，fputcsv需要数字索引，漏这步在 PHP 8.4 下导出内容会是"Array","Array","Array"
真正麻烦的从来不是函数怎么调，而是 CSV 本身没有强制标准：换行符可能是 \n、\r\n 或 \r，字段里嵌了换行或逗号也不报错，Excel 和 LibreOffice 解析规则还不一样。所以只要涉及用户上传，就得默认它“不可信”，校验列数、过滤控制字符、强制转义，比选什么 PHP 版本重要得多。
