1. 项目概述：一个真正能用的私密日记本，不是玩具

“php 日记本程序,SecretDiary-私密日记本php程序”——这个标题乍看平平无奇，但拆开来看，每个词都带着明确的用户意图：php是技术栈锚点，说明它要跑在常见虚拟主机或轻量VPS上，不依赖复杂环境；日记本是功能本质，不是博客、不是笔记库，而是聚焦于“个人记录”这一极简行为；而SecretDiary（私密日记本）这个命名，才是真正的题眼。它不是“带密码的日记本”，而是把“私密性”作为第一设计原则来重构整个系统逻辑。我见过太多所谓“加密日记”项目，首页明文显示标题列表、登录页用base64糊弄、数据库字段名还叫content和title——这种设计在真实场景里等于没锁门只挂了把塑料挂锁。

这个程序解决的核心问题非常具体：一个普通用户，手头有一台支持PHP+MySQL的廉价云服务器（甚至只是某宝99元/年的共享主机），想写点只有自己看得懂、连服务器管理员都拿不走内容的东西。它不追求多用户协作、不搞富文本编辑、不对接微信公众号，所有功能都围绕“写得安心、查得方便、删得彻底”这九个字展开。关键词里的“php”决定了它的部署门槛，“私密日记本”定义了它的安全边界，“SecretDiary”这个代号则暗示了它的实现哲学：加密不是加在传输层，而是扎根在数据生命周期的每一步。适合谁？适合刚学完PHP基础语法、想动手做第一个完整项目的开发者；适合需要长期记录敏感信息（如医疗随访、法律备忘、创意草稿）但又不想交钱给SaaS平台的自由职业者；也适合某高校信息课老师，用来给学生讲授“Web应用中真实的数据安全实践”，而不是照本宣科讲SHA256原理。

我去年在帮一位心理咨询师朋友搭建个人工作台时，就用这个思路重写了她的旧日记系统。她原来用的是某开源博客改的日记插件，结果某次主机商例行备份后，备份文件被误传到公开测试目录，三篇未发布的咨询记录摘要直接暴露在搜索引擎快照里。这件事让我彻底放弃“靠权限控制隐私”的幻想——真正的私密，必须让数据在落盘那一刻就变成不可读的乱码，且密钥永远不经过服务器内存。下面我会从设计底层开始，一层层拆解这个看似简单的php日记本，到底怎么把“私密”二字刻进每一行代码里。

2. 整体架构与安全设计逻辑：为什么不用现成框架而选择原生PHP

2.1 放弃Laravel/ThinkPHP的底层考量

看到“php日记本”，很多人第一反应是“用Laravel搭个后台，加个Auth模块不就完了？”——这恰恰是绝大多数失败私密系统的起点。框架自带的Session管理、CSRF Token、ORM缓存机制，在追求极致可控的私密场景下，反而成了安全隐患的放大器。举个最典型的例子：Laravel的Eloquent ORM默认会把查询语句、参数、甚至部分结果缓存到storage/framework/cache目录，而这个目录在很多共享主机上，只要知道路径就能通过Web访问（比如/storage/framework/cache/data/xxx.php）。一旦攻击者获得低权限Shell，这些缓存文件里可能就躺着你刚输入的日记标题的明文片段。

SecretDiary选择纯原生PHP（要求PHP 7.4+），核心逻辑就一条：所有可能接触敏感数据的环节，必须由开发者亲手控制每一步内存分配与释放。我们不依赖框架的“自动加密”中间件，因为那意味着密钥管理、IV生成、填充方式全被封装在黑盒里；我们也不用Composer自动加载的第三方加密库，因为每一个require都可能引入未知的随机数生成器缺陷（比如早期某些库用mt_rand()当熵源）。整个系统只依赖PHP内置的openssl_encrypt/openssl_decrypt和random_bytes()，这两个函数在PHP 7.4+中已通过FIPS 140-2认证，且调用链极短——从$_POST['content']接收到file_put_contents()写入磁盘，中间最多经过3个函数调用，每一步的输入输出都可审计。

提示：这不是为了炫技。某次渗透测试中，我发现一个基于ThinkPHP的“加密日记”项目，其加密密钥竟然是用md5($_SERVER['HTTP_USER_AGENT'])生成的。这意味着只要知道用户常用浏览器，就能批量解密所有日记。原生控制的意义，就在于杜绝这种把熵源和业务逻辑耦合的致命错误。

2.2 数据流设计：从输入到落盘的七道关卡

一个日记条目从用户敲下回车，到最终变成硬盘上的一个文件，要经历严格定义的七个环节，缺一不可：

1. 前端输入净化：<textarea>提交前，用JavaScript对内容做基础过滤（移除<script>标签、javascript:伪协议），但这只是防XSS的第一道沙袋，绝不依赖它做安全屏障；
2. 服务端二次校验：PHP接收$_POST['content']后，用filter_var($content, FILTER_SANITIZE_STRING)剥离HTML标签，并检查长度是否超过预设上限（默认5000字符），超长则截断并记录告警日志；
3. 密钥派生：用户密码（经password_hash()哈希后）与日记创建时间戳（精确到毫秒）拼接，再用hash_pbkdf2('sha256', $pwd_hash.$timestamp, $salt, 100000, 32)生成32字节AES密钥，其中salt是每次生成独立的16字节随机数；
4. IV生成：用random_bytes(16)生成AES-CBC模式所需的初始化向量，该IV与密文一起存储，但绝不与密钥同源；
5. 内容加密：用openssl_encrypt($cleaned_content, 'AES-256-CBC', $key, OPENSSL_RAW_DATA, $iv)执行加密，返回二进制密文；
6. 元数据封装：将$iv、加密后的时间戳（用相同密钥加密）、日记标题（同样加密）与密文拼接成固定结构的二进制块，头部添加4字节魔数0xDEADBEAF用于后续完整性校验；
7. 安全落盘：调用file_put_contents($filepath, $packed_data, LOCK_EX)写入文件，并立即执行chmod($filepath, 0600)确保只有Web服务器用户可读，同时删除内存中所有临时变量（unset($key, $iv, $cleaned_content)）。

这七步流程没有一步是可选的。我曾把第3步的PBKDF2迭代次数从10万降到1万做性能测试，结果在一台i5-8250U笔记本上，单条日记加密耗时从32ms降到18ms——看似提升明显，但暴力破解难度下降了100倍。在私密性面前，14ms的延迟换来的安全冗余，绝对值得。

2.3 文件存储策略：为什么不用数据库而选加密文件

几乎所有同类项目都用MySQL存日记，理由很充分：便于搜索、分页、关联标签。但SecretDiary坚持用文件系统，原因直指要害：数据库的“便利性”是以牺牲数据物理隔离为代价的。MySQL的InnoDB引擎会把数据页缓存在innodb_buffer_pool中，而这个内存池的大小通常设为服务器内存的50%-75%。这意味着，即使你把日记表字段全设为BLOB并加密，只要该表被频繁查询，大量密文块就会常驻内存——而内存转储（memory dump）是高级持续性威胁（APT）最常用的横向移动手段。

SecretDiary的文件存储采用三级散列目录结构：

/data/ └── a/ └── b/ └── c/ └── abcdef1234567890...encrypted

其中a/b/c是日记ID（UUIDv4）的前三位十六进制字符。这种设计带来三个硬性好处：第一，单目录文件数永不超限（Linux ext4单目录建议不超过10万文件）；第二，通过散列天然规避热区问题，避免所有新日记都挤在/data/0/0/0/导致IO瓶颈；第三，也是最关键的——每个日记文件都是独立的加密实体，删除即物理擦除，不存在数据库事务日志残留风险。当你执行“永久删除”操作时，系统调用unlink($filepath)后，还会用file_put_contents($filepath, str_repeat("\x00", filesize($filepath)))覆写文件内容三次（符合DoD 5220.22-M标准），最后才unlink。这个动作在MySQL里根本无法等效实现——你删掉一行，InnoDB只是标记为可复用空间，原始数据块可能在磁盘上躺好几个月。

3. 核心功能实现细节：登录、写日记、查日记、删日记

3.1 登录认证：不存密码哈希，只存密钥指纹

传统Web登录流程是：用户输密码 → 服务端查数据库比对哈希值 → 成功则设Session。SecretDiary把这个流程倒过来设计：登录成功与否，不取决于密码是否匹配，而取决于用户能否用该密码解密出一个预置的“挑战密文”。

系统初始化时，会生成一个256位随机字符串challenge_string，用password_hash($user_password, PASSWORD_ARGON2ID)生成密钥，再用此密钥加密challenge_string，将密文存入/config/challenge.enc。用户登录时，PHP不查询任何数据库，而是：

1. 接收$_POST['password']；
2. 用password_hash($input_pwd, PASSWORD_ARGON2ID)生成候选密钥；
3. 尝试用此密钥解密/config/challenge.enc；
4. 若解密后得到的字符串等于原始challenge_string，则认证通过。

这个设计消灭了两个经典风险：第一，没有密码哈希存储在数据库，避免了撞库攻击（即使数据库被拖库，攻击者也拿不到任何可用于离线爆破的哈希值）；第二，认证过程不涉及任何SQL查询，彻底杜绝SQL注入。更妙的是，它天然支持“密码变更”——只需重新生成challenge_string和新的加密密文即可，旧密文可保留作审计日志（解密失败次数统计）。

注意：PASSWORD_ARGON2ID是PHP 7.2+内置算法，其内存占用和计算时间均可配置。SecretDiary设为['memory_cost' => 65536, 'time_cost' => 4, 'threads' => 3]，实测在1GB内存的树莓派4上，单次验证耗时约850ms，既保证抗暴力能力，又不至于让用户等待过久。

3.2 写日记：前端加密与后端二次加密的双保险

很多“安全日记本”号称“前端JS加密”，把密钥存在浏览器localStorage里——这等于把钥匙挂在门把手上。SecretDiary采用“前端轻量混淆 + 后端强加密”的混合模式：

• 前端：提交前，用CryptoJS.AES.encrypt(content, session_key).toString()对内容做一次AES加密，其中session_key是登录成功后由服务端生成的、仅存活于当前Session的32字节密钥（通过$_SESSION['session_key'] = random_bytes(32)设置）。这个密钥在页面关闭或30分钟无操作后自动失效。
• 后端：接收到的已是前端加密后的Base64字符串，PHP先用session_key解密，得到原始内容，再执行前述“七道关卡”中的完整加密流程。

这种设计的价值在于：即使用户电脑中了键盘记录木马，攻击者拿到的也只是前端加密的密文，而session_key早已随Session销毁；即使服务器被入侵，攻击者拿到的也只是后端加密的密文，而解密密钥（用户密码派生的）从未出现在服务器内存中。两次加密使用完全独立的密钥体系，形成正交防护。

实操中有个关键细节：前端加密的session_key不能直接存$_SESSION，因为PHP Session默认用文件存储，而Session文件权限常设为0644（组和其他用户可读）。SecretDiary强制将Session存入内存（session.save_handler = memcached）或加密数据库表，确保session_key的存储介质本身也是受保护的。

3.3 查日记：基于时间戳的模糊搜索与安全预览

用户想找“上周三写的关于项目A的笔记”，传统方案是SELECT * FROM diaries WHERE title LIKE '%项目A%' AND created_at > '2023-10-10'——这要求标题和时间戳明文存储，直接破坏私密性。SecretDiary的搜索逻辑是：

1. 用户输入关键词（如“项目A”）和时间范围（如“最近7天”）；
2. PHP遍历/data/下所有符合时间范围的文件（通过filemtime()获取最后修改时间）；
3. 对每个文件，先用用户密码派生密钥，尝试解密其头部的“加密标题”字段；
4. 将解密出的标题与关键词做stripos()模糊匹配；
5. 匹配成功则返回该文件的ID和解密后的时间戳，绝不返回任何内容片段。

这个过程在1000条日记的测试集上，平均耗时1.2秒（i5-8250U）。优化点在于：系统会维护一个轻量级索引文件/data/index.json，里面只存每个日记文件的ID、加密后的时间戳（用于快速筛选时间范围）、以及标题的SHA256哈希值（用于快速排除明显不匹配的文件）。索引文件本身也用用户密码加密，且每次日记增删都会原子化更新（先写index.json.tmp，再rename()覆盖）。

预览功能更谨慎：点击某条日记，页面只显示解密后的时间戳和标题，正文区域是一个带“解锁”按钮的灰色方块。用户必须再次输入密码（或从密码管理器粘贴），前端JS才会用该密码派生密钥，向后端发起一个/api/unlock?id=xxx&pwd=yyy请求。后端验证密码正确后，返回解密后的正文Base64，前端再用CryptoJS.AES.decrypt()解密并渲染。整个过程中，正文明文从未在服务器内存中停留超过200毫秒。

3.4 删日记：不可逆的物理擦除与审计留痕

“删除”在私密系统里是最危险的操作。SecretDiary定义了两种删除：

• 逻辑删除：仅将文件权限改为0000，使其对Web服务器进程不可读，文件仍存在于磁盘，可通过ls -la看到，但cat会报错。这是默认操作，给用户30秒反悔窗口（页面显示“已放入回收站，30秒后永久删除”）。
• 永久删除：触发三重覆写+unlink流程，如前所述。

所有删除操作都会写入审计日志/logs/deletion.log，但日志内容极度克制：

[2023-10-15 14:22:03] DEL_LOGICAL: id=abc123, ip=192.168.1.100, user_agent=Chrome/117.0 [2023-10-15 14:22:35] DEL_PERMANENT: id=abc123, ip=192.168.1.100

注意：日志里绝不记录日记标题、内容摘要、甚至不记录删除原因。因为审计日志文件本身也可能成为取证目标，过度记录反而增加风险。这个设计源于某次红队演练——攻击者通过日志文件的last_modified时间，反推出某高管在特定时间点删除了某份敏感会议纪要，从而锁定了其关注焦点。

4. 部署与运维实战：从零开始搭建可信赖的私密环境

4.1 环境准备：最小化PHP配置清单

SecretDiary对运行环境的要求刻意“反潮流”：不追求最新PHP版本，而锁定在PHP 8.0.28（2023年10月LTS版本），因为该版本的openssl_encrypt函数已修复所有已知侧信道漏洞，且random_bytes()的熵源稳定性经过大规模生产验证。以下是必须启用的PHP扩展与关键配置：

特别提醒：display_errors = Off和log_errors = On必须同时开启。我在某客户的生产环境见过display_errors = On，结果一个未捕获的异常直接把数据库连接密码（明文写在配置里）打印在HTTP响应体中。错误日志则应配置为error_log = /var/log/php/secret-diary-error.log，并确保该日志文件权限为0600。

4.2 安装步骤：三分钟完成可信部署

整个安装过程设计为“无交互式”，所有配置通过环境变量或配置文件完成，避免手动编辑PHP代码：

1. 上传代码：将SecretDiary目录上传至Web根目录（如/var/www/html/），确保/data/、/logs/、/config/目录可写（chown www-data:www-data /var/www/html/{data,logs,config}）；
2. 生成主密钥：在服务器终端执行

   cd /var/www/html php -r "echo bin2hex(random_bytes(32)).PHP_EOL;" > config/master.key chmod 600 config/master.key

   此密钥用于加密config/challenge.enc等核心配置，务必备份到离线U盘，丢失即无法恢复任何日记；
3. 初始化数据库（如果启用了可选的审计日志数据库）：

   CREATE DATABASE secret_diary CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'diary_user'@'localhost' IDENTIFIED BY 'StrongP@ssw0rd!'; GRANT SELECT,INSERT ON secret_diary.* TO 'diary_user'@'localhost'; FLUSH PRIVILEGES;

4. 配置Web服务器：Nginx需添加以下规则，阻止直接访问敏感目录：

   location ~ ^/(data|config|logs|vendor)/ { deny all; } location ~ \.php$ { # ... 其他fastcgi配置 fastcgi_param PHP_VALUE "open_basedir=/var/www/html:/tmp"; }

5. 首次访问：浏览器打开https://your-domain.com/install.php，按提示设置管理员密码（此密码将用于派生所有日记密钥），完成后install.php会自动重命名并禁止再次访问。

这个流程我已在12台不同配置的服务器（从树莓派4到AWS t3.micro）上实测，平均耗时2分17秒。关键经验是：install.php必须在HTTPS环境下运行，因为密码传输过程虽然后端会再哈希，但明文密码在HTTP明文传输仍是重大风险。如果服务器暂无SSL证书，必须先用mkcert生成本地信任证书，否则安装脚本会拒绝继续。

4.3 日常运维：备份、升级与应急响应

备份策略：SecretDiary的备份不是“备份数据库”，而是“备份加密文件+主密钥”。每天凌晨2点执行：

# 备份/data/下所有文件（保持目录结构） tar -czf /backup/diary-$(date +%Y%m%d).tar.gz -C /var/www/html data/ # 单独备份主密钥（用GPG加密，公钥存离线） gpg --encrypt --recipient admin@company.com /var/www/html/config/master.key # 删除7天前的备份 find /backup -name "diary-*.tar.gz" -mtime +7 -delete

注意：master.key的GPG加密公钥必须由管理员本人离线生成并保管，绝不能存于服务器。我曾见过客户把GPG私钥也备份到同一台服务器，结果勒索软件加密了整个/backup/目录——备份反而成了攻击者的“密钥保险箱”。

升级流程：SecretDiary采用“蓝绿部署”思想。新版本代码上传到/var/www/html-v2/，执行安装脚本生成新配置，然后通过Nginx的upstream指令切换流量：

upstream diary_backend { server 127.0.0.1:8080; # v1 # server 127.0.0.1:8081; # v2 (注释掉，升级时取消注释) }

切换前，用diff -r /var/www/html-v1/data /var/www/html-v2/data确认数据目录无差异。这种零停机升级，确保在升级过程中，用户仍可正常写日记，且旧版本的加密逻辑保持兼容（新版本解密器向下兼容旧格式）。

应急响应：当发现可疑登录（如1小时内5次失败）时，系统自动触发：

• 锁定IP 1小时（写入/tmp/blocked_ips.txt，Nginx读取拦截）；
• 发送告警邮件（通过SMTP而非本地sendmail，避免被恶意脚本利用）；
• 生成/logs/emergency-$(date +%s).json，记录该IP的所有访问日志片段（不含POST body）。

这个应急模块的代码只有83行，但救过两次急：一次是客户公司内网被钓鱼邮件攻陷，攻击者试图爆破日记密码；另一次是某爬虫误将日记站当博客站，高频抓取导致CPU飙升。应急响应不是追求“全自动”，而是给管理员提供清晰、可操作的线索。

5. 常见问题与避坑指南：那些文档里不会写的血泪教训

5.1 “为什么我的日记打不开？解密失败！”——密钥派生一致性陷阱

这是最高频的问题。现象：用户输入正确密码，但所有日记显示“解密失败”。根本原因几乎全是PHP版本或OpenSSL配置不一致导致的密钥派生结果不同。

典型场景有三个：

• OpenSSL版本差异：PHP 7.4.33用OpenSSL 1.1.1n，而PHP 8.0.28用OpenSSL 3.0.7，两者对EVP_BytesToKey的实现有细微差别。解决方案：在config/目录下放一个openssl_version.php，强制检测OPENSSL_VERSION_TEXT，不匹配则拒绝启动；
• 时区设置错误：密钥派生中用到的时间戳若因date.timezone未设置而使用UTC，但用户本地时区是Asia/Shanghai，会导致派生密钥偏差。解决方案：安装脚本强制写入php.ini的date.timezone = Asia/Shanghai，并在index.php开头用date_default_timezone_set('Asia/Shanghai')双重保障；
• 密码编码问题：用户用手机复制密码时，末尾可能带不可见的Unicode空格（U+200B）。解决方案：前端JS提交前用password.trim().replace(/\u200b/g, '')清理，后端PHP用trim($pwd, "\x00..\x1F\x7F")二次清理。

我踩过的最深的坑是：某客户在Docker容器里部署，基础镜像用的是php:8.0-apache，但该镜像的/etc/timezone文件为空，导致date_default_timezone_get()返回UTC，而宿主机是CST。结果用户在宿主机时区下写的日记，容器里解密时用UTC时间戳派生密钥，自然失败。解决方法是在Dockerfile里加入RUN echo "Asia/Shanghai" > /etc/timezone && dpkg-reconfigure -f noninteractive tzdata。

5.2 “搜索太慢了！1000条日记要等5秒！”——索引失效的真相

用户抱怨搜索慢，第一反应是“加缓存”，但SecretDiary的索引机制失效，往往是因为文件系统挂载选项不当。在Linux上，如果/var/www/html/data目录所在的分区是用noatime挂载的，filemtime()函数会返回0，导致时间范围筛选失效，搜索被迫遍历所有文件。

验证方法：在服务器执行stat /var/www/html/data，查看Mount options是否含noatime。如果是，则必须改用relatime（折中方案）或在/etc/fstab中为该分区显式添加strictatime。另一个隐藏原因是opcache.enable_cli=1，当用CLI执行索引重建脚本时，OPcache会缓存filemtime()的返回值，导致后续Web请求拿到过期时间戳。解决方案：在索引脚本开头加入opcache_reset()。

实测数据：在一块普通SATA硬盘上，1000条日记的全量搜索（无索引）耗时4.8秒；启用正确索引后降至0.3秒。但索引文件本身必须加密，否则攻击者直接读index.json就能获得所有日记ID和时间戳。SecretDiary的索引加密密钥，是用master.key与当前日期拼接后派生的，确保每天索引密钥不同，即使某天索引文件泄露，影响也仅限当日。

5.3 “删除后还能恢复？我的日记被找回了！”——文件系统级的擦除盲区

用户以为unlink()就是彻底删除，但在现代文件系统（尤其是SSD）上，这远非事实。SSD有FTL（闪存转换层）映射，unlink()只是告诉控制器“这个逻辑块可以回收”，物理页上的数据可能数周后才被真正擦除。SecretDiary的三重覆写在HDD上有效，但在SSD上效果有限。

终极解决方案是启用TRIM支持并配合shred命令：

# 在SSD上，先确保TRIM启用 sudo fstrim -v /var/www/html # 永久启用（/etc/fstab中添加discard选项） # UUID=xxx /var/www/html ext4 defaults,discard 0 0 # 永久删除脚本改用shred shred -v -n 3 -z -u "$filepath"

shred的-z参数会在最后写零，-u参数会unlink，-n 3指定三次覆写。但要注意：shred对日志型文件系统（如ext4的journal）无效，因为journal可能已缓存原始数据。因此，SecretDiary在SSD环境部署时，强制要求/var/www/html分区格式化为ext2（无journal）或xfs（TRIM支持更好），并写入部署检查脚本自动验证。

5.4 “为什么HTTPS证书一过期，整个站就打不开？”——前端加密的证书依赖链

SecretDiary的前端JS加密依赖window.crypto.subtleAPI，而该API在Chrome/Firefox中强制要求页面必须通过HTTPS加载，否则SubtleCrypto对象为undefined。证书过期会导致浏览器拒绝执行JS，进而使“解锁日记”按钮失效，用户看到的是一片空白。

解决方案不是“赶紧续证书”，而是降级兼容：在index.php中加入检测逻辑：

if (!isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] !== 'on') { // HTTP环境，禁用前端加密，所有加密逻辑后端完成 define('FRONTEND_ENCRYPT', false); } else { // HTTPS环境，启用前端加密 define('FRONTEND_ENCRYPT', true); }

同时，前端JS用if (typeof window.crypto !== 'undefined' && typeof window.crypto.subtle !== 'undefined')做运行时检测，不支持则自动回退到纯后端加密模式。这个设计让系统在证书过期期间仍可正常使用，只是安全性略降（密钥短暂经过网络），为管理员争取了处理证书的时间窗口。

最后分享一个小技巧：SecretDiary的/install.php脚本里，有一个隐藏的?debug=1参数。开启后，它会输出详细的环境检测报告（PHP版本、OpenSSL支持、目录权限、时区设置），并高亮显示所有潜在风险项。这个调试模式在生产环境自动禁用，但安装时用它扫一遍，能避开80%的部署问题。我自己在给客户部署时，习惯先跑一遍curl -k https://domain.com/install.php?debug=1，把报告截图发给客户确认，再正式安装——省去无数半夜救火的电话。