用途：在会话首次提交前做一次只读、有时限的检查，确认 Git 提交签名会正常工作，即签名密钥已加载并已解锁。资料称，若密钥被锁，应在动工前先向操作者问一次，值得为此暂停。
主要能力与检查方式：先读取配置确认是否期望签名，使用 git config --get commit.gpgsign、git config --get gpg.format（ssh | openpgp，空值表示 openpgp）、git config --get user.signingkey。随后按格式做一次限时测试签名：SSH 用 ssh-keygen -Y sign -n git -f "$K"，其中 user.signingkey 可能是密钥文件，也可能是字面量 key::ssh-…；OpenPGP 用 gpg --batch --pinentry-mode error --clearsign -u。两者都以 perl -e 'alarm 5; exec @ARGV' 设置超时，因为对已锁密钥的无超时签名会等待无人输入的密码，令会话停滞。
结果处理：测试能签名则继续，不必多言；输出 CANNOT-SIGN 时，在任何工作前向操作者提问，请其解锁（ssh-add / gpg-agent）或明确允许本次会话不签名提交。
限制与注意事项：未经明确指示，不要使用 git -c commit.gpgsign=false commit 或 --no-gpg-sign；在要求签名的分支上提交未签名内容可能导致推送被拒，或被接受而更糟。也不要重写历史（rebase --exec 'git commit --amend -S'），它会改动触及的第一个提交之后的全部哈希；在已推送分支上等同强制推送。若最终仍产生了未签名提交，应如实报告，可用 git log --format='%h %G? %s' @{upstream}..HEAD | awk '$2!="G"' 列出。资料中的历史教训包括：代理未经询问就提交未签名内容、签名调用在锁定 SSH 密钥上挂起、事后需重签 121 个提交，而该密钥其实根本没有密码短语。