「日志」标签下共 26 篇技术文章，包括《自动化的失败路径：幂等、超时与回滚该在脚本里怎么落》、《Nginx 与 PHP-FPM 调优：先定位瓶颈，再决定改哪》、《API 密钥安全：泄露风险从哪里来，防护要落到哪几步》。按发布时间倒序排列，内容持续更新。
效率工具的长期收益取决于失败时能否安全重放。写脚本前应先判断重复执行会改变什么，再用幂等键、显式超时、有上限的重试、能回答三个问题的日志，以及可停止的开关来约束副作用；一次性操作和代价不可逆的操作更适合人工清单而非自动化。
Nginx 与 PHP-FPM 调优应先区分连接层、转发层、执行层与超时层的信号，再改参数。pm.max_children 受内存约束，FPM 终止超时与 Nginx 读取超时不应倒挂，listen.backlog 需与内核 som…
API 密钥是“持有即授权”的凭证，防护重点在于缩小暴露面、按用途拆分并最小化权限、保证可轮换与可追溯。前端、仓库、日志、共享渠道和中间层是常见泄露面；泄露后应先在服务端吊销，再排查调用范围并修复根因。API.PLUS 平台侧的具体…
eval 分数只说明 agent 是否完成任务，轨迹才记录它绕了哪些路。本文基于 Microsoft 博客对 Dev Proxy 的一次评估，归纳 404 路径猜测、错误信息缺有效值、跨运行重复绕过、模型记忆补文档缺口、默认配置被绕…
API 密钥通常同时承担身份和权限两个作用，一旦泄露，损失范围不容易收窄。本文按密钥的存放位置说明常见的泄露途径，给出服务端持有、最小权限、轮换与吊销、日志脱敏四类实践，并指出具体平台的密钥格式、权限模型与轮换能力需以官方文档为准。…
API 密钥应默认放在服务端，并假定它可能泄露：先把密钥从浏览器、URL、日志和仓库历史中移除，再让它可分环境、可撤销、可轮换。判定泄露看的是密钥是否出现在未授权者可读的位置，而不是它有没有被滥用。API.PLUS 是否提供分项目密…
API 密钥一旦进入公开仓库、客户端包或日志，应按已泄露处理：先吊销或轮换，再把保密密钥收口到服务端，并以最小权限、日志脱敏、扫描和可追踪轮换降低复发风险；API.PLUS 的具体密钥管理能力需核实。
API 密钥的主要风险不是强度不足，而是它会随前端产物、版本库历史、URL、日志和人员操作扩散到服务端之外。防护按“密钥只留服务端、按环境和用途拆分、事前跑通轮换、统一日志脱敏、仓库侧拦截”推进；发现泄露后先吊销再调查。文中给出服务…
本次只获得“网站 SEO 技术优化清单”这一标题，没有可读正文，因此文章不涉及搜索引擎最新规则或排名因素。正文把检查限定在开发者能自行获取证据的三层：抓取可达性、索引标签与渲染后结果、可重复执行的回归脚本，并说明这些观察能推出什么、…
共 26 篇文章，第 1 / 3 页