curl 已保存 Cookie，下一条命令仍然没有会话

第一条 curl 命令已经用 -c session.cookies 保存 Cookie，第二条请求却又被当作未登录用户。即使第二条也写了 -c session.cookies，它仍不会自动读取这个文件。

-c（--cookie-jar）指定输出文件，-b（--cookie）才负责从文件加载 Cookie。两个独立的 curl 进程不共享内存里的会话状态。

下一次请求需要读取文件

如果第一步已经得到了服务器认可的会话，后续请求应同时读取 Cookie 文件并保存服务器可能更新的内容：

curl --cookie session.cookies \
     --cookie-jar session.cookies \
     'https://app.example.com/account'

只写 -b 可以读取，但不会把新收到或更新的 Cookie 保存回文件。只写 -c 会启用 Cookie 引擎，并在本次操作结束时写出内存里的 Cookie，却不会载入之前保存的内容；如果本次没有 Cookie，仍可能写出没有会话条目的文件，覆盖旧状态。

文件参数不要含 =。--cookie 的参数中存在等号时，会被当成直接给出的 Cookie 数据，而不是文件名。通常使用不含等号的绝对路径，更容易避免工作目录变化或同名文件造成误读。

把一次测试会话放在独立私有目录

以下适用于 Unix 类系统的 shell。两个 URL 是占位地址，必须替换成应用允许测试的会话建立入口和只读状态页；这里的 GET 请求不代替应用实际要求的登录方法、表单或认证流程。

umask 077
cookie_dir=$(mktemp -d) || exit 1
cookie_jar="$cookie_dir/session.cookies"

curl --fail --silent --show-error \
     --cookie-jar "$cookie_jar" \
     --output /dev/null \
     'https://app.example.com/session/start' || exit 1

test -f "$cookie_jar" && test -r "$cookie_jar" || exit 1

curl --fail --silent --show-error \
     --cookie "$cookie_jar" \
     --cookie-jar "$cookie_jar" \
     --output /dev/null \
     'https://app.example.com/account'

这段示例需要在同一个 shell 中执行，让两个命令使用同一路径。目录权限和 umask 用于保护新文件；不要把 jar 放进代码仓库、公共目录或共享日志，也不要把 Cookie 值写在命令行上。不同账户或并发任务各用自己的 jar，避免后完成的进程覆盖另一条流程刚更新的状态。

这里没有自动跟随重定向。若应用的会话流程确实依赖跳转，应先确认目的地址可信，再按实际流程添加 --location；不能把重定向响应被取回当作登录成功，也不能靠 jar 绕过应用的其他认证要求。

文件存在不等于会话有效

curl 无法创建或写入 Cookie 文件时，整个传输不一定返回失败；详细输出中可能只有一条警告。因此，HTTP 成功和退出码为零不能单独证明状态已保存。上面的文件检查能发现首次没有生成可读文件，但不能证明文件里有适用的 Cookie，已有旧文件的情况更要核对更新结果。

在受控本地环境检查 jar 的域名、路径、过期时间和 Secure 标记，遮盖值；再对照目标 URL。Cookie 已过期、域名不匹配、路径不匹配或 Secure Cookie 用于普通 HTTP 请求时，都可能不发送。不要为了让请求“带上值”就改成手写无范围限制的 Cookie 请求头。

还应检查第二次响应是否真的表示预期账户的会话状态，而不是仅有 200 的登录页面。确需查看请求头时，只在隔离环境中短暂使用详细输出并保护日志，因为它可能包含认证信息。不要把整份输出公开。

结束测试后清理本次状态

确认不再使用该测试会话后，可在仍保留这两个变量的同一 shell 中清理刚创建的专用文件和空目录：

rm -- "$cookie_jar"
rmdir -- "$cookie_dir"

只操作本次创建的路径，不删除其他任务的 jar。删除本地文件不会使服务器端会话自动失效；需要撤销会话时仍应使用应用的退出或撤销功能。如果只是回退脚本参数，保留原有应用认证流程，去掉本次新增的 jar 读写即可。