需求分析不是写文档，是确认“谁在什么场景下用什么功能解决什么问题”
PHP项目的需求分析，本质是把模糊的业务意图翻译成可验证的技术输入。很多人一上来就列功能点、画流程图，结果开发到一半发现老板说的“用户能上传文件”其实特指“销售同事用IE8在内网传Excel报表”，根本没考虑兼容性和权限隔离。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先问清楚
触发动作：是用户点击按钮？定时任务？还是第三方API回调？不同触发方式直接决定你用$_POST还是file_get_contents('php://input') - 记录每个功能的
前置条件和失败后果。比如“导出订单”功能，要明确写清：“必须已登录且角色为admin；若订单超10万条，不生成Excel而返回429 Too Many Requests” - 拒绝“支持多语言”这种空话。改成：“首页
header.php中所有文案必须从$lang['welcome']读取，且zh_CN和en_US两个配置文件已存在”
别在需求文档里写PHP代码，但得标出关键函数和扩展依赖
需求文档不是技术方案，但开发者需要立刻判断是否要装扩展、改php.ini，或放弃某个现成库。比如写“图片压缩上传”，如果没注明“需支持WebP格式”，开发可能默认用imagejpeg()，上线后发现安卓微信里全是黑图。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 凡涉及文件处理，必须标注预期的
max_file_size和upload_max_filesize值。例如：“头像上传限2MB，需在php.ini中确认post_max_size >= 2M” - 数据库操作类需求，明确是否允许
PDO::prepare()——有些老系统禁用预处理，只能拼SQL（虽不推荐，但需求得承认现实） - 如果依赖
ext-redis或ext-memcached，直接写进“环境要求”章节，别等联调时才发现Docker镜像没装扩展
“用户登录”这种通用功能，在PHP需求里最容易埋雷
看似简单，但PHP项目里$_SESSION生命周期、session.cookie_httponly开关、CSRF token生成位置、密码重置链接有效期……任何一个没写进需求，测试阶段就会冒出一堆“为什么登出后还能访问订单页”的问题。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 明确
session_start()调用位置：是每个入口脚本都调？还是只在auth.php里集中管理？这关系到并发登录踢出逻辑能否生效 - 写清token存储方式：
$_SESSION['csrf_token']还是$_COOKIE['XSRF-TOKEN']？前者依赖session，后者需额外校验 - 密码策略不能只写“8位以上”，要定义
password_hash($pass, PASSWORD_ARGON2ID)还是PASSWORD_DEFAULT，避免PHP升级后哈希失效
需求文档里最该加粗的，是“不做什么”
PHP项目常因“默认支持”引发纠纷。比如没写明“不兼容PHP 5.6”，结果运维在CentOS 7上部署，发现??空合并运算符报错；或者写了“支持手机访问”，却没限定“仅适配Chrome for Android最新版”，结果iOS Safari里表单提交丢失$_FILES。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在文档开头单独列“明确不支持项”：例如“不支持IE11以下浏览器”“不兼容
mysql_*()扩展”“不处理GD库未启用时的降级方案” - 对第三方服务写死版本：如“微信支付SDK使用
v3.0.9，不保证与v3.1.0兼容” - 性能边界必须量化：“列表页加载时间≤1.2s（基于AWS t3.micro + MySQL 5.7），超时则显示
503 Service Unavailable”
需求分析最难的不是写清楚要什么，而是敢把“不能做”“不做”“不该由PHP做”钉死在纸面上。否则开发完才发现“前端要WebSocket实时通知”，而你的需求里只写了“用户提交后跳转成功页”，那就不是改代码，是返工重聊。
