技术架构应从变化频率和团队能力出发
最复杂的架构并不自动带来更高可靠性。
语义化 HTML 是可访问性和维护性的底座
全部使用 div 模拟控件，会失去浏览器原生行为和辅助技术支持。
CSS 组织应控制作用域、依赖和覆盖顺序
不断追加高优先级规则，会让小改动产生不可预测回归。
渐进增强让核心任务不依赖复杂脚本
把所有内容和导航交给 JavaScript，会放大加载和失败风险。
PHP 项目也需要清楚的业务边界
路由、查询和 HTML 混在一个文件中，会增加测试和修改成本。
数据库索引应服务真实查询而不是越多越好
缺少索引会变慢，重复索引又会增加写入和维护成本。
数据库变更需要可重复、可回滚的迁移流程
手工改生产库会造成环境差异和不可追溯风险。
API 契约要稳定表达资源、错误和版本
仅记录成功示例，会让客户端在边界场景中自行猜测。
登录安全不仅是密码哈希
会话固定、弱 Cookie 属性和无限尝试都可能绕过账号保护。
CSRF 与 XSS 需要在输入和输出两端防护
只过滤特定字符无法覆盖不同 HTML、属性和脚本上下文。
输入验证必须以服务器端规则为准
前端校验改善体验，但可以被绕过。
文件上传要按不可信输入处理
只检查扩展名无法阻止伪装文件和资源消耗。
密钥和密码不应进入代码仓库
删除提交后的密钥并不能消除历史泄露风险。
日志要支持定位问题，同时保护敏感数据
记录所有请求正文可能泄露密码、令牌和个人信息。
监控应从用户可感知的服务目标开始
只看 CPU 和内存，无法及时发现结算失败或页面不可用。
备份只有经过恢复演练才可信
任务显示成功，不代表文件完整、密钥可用或恢复时间可接受。
缓存设计要先确定失效和一致性策略
盲目增加缓存层会产生旧数据、击穿和难以复现的问题。
CDN 需要正确的缓存键和源站保护
忽略查询、Cookie 或区域差异，可能把个性化内容发给错误用户。
图片优化应自动进入构建和上传流程
依赖人工压缩会随着内容更新迅速失效。
性能优化要同时观察加载、交互和稳定性
只压缩文件大小无法解释主内容慢、交互延迟和布局跳动。
HTTP 缓存头应与资源版本策略配合
长期缓存却不改文件名，会让用户持续看到旧资源。
错误处理要区分用户反馈、日志和恢复动作
把异常详情直接显示给用户既难理解又可能泄露路径和查询。
依赖升级需要持续、小步和可验证
长期冻结版本会积累安全风险，一次性大升级又放大回归范围。
持续集成应快速阻止可预见的回归
流水线过慢或结果不稳定，会让团队绕过检查。
测试组合要覆盖规则、集成和关键用户路径
只依赖端到端测试会慢且难定位，只做单元测试又会漏掉配置问题。
安全响应头可以降低常见浏览器攻击面
缺少策略会让点击劫持、内容嗅探和脚本注入更容易扩大。
自动化无障碍测试只能覆盖一部分问题
通过扫描不代表键盘顺序、文案理解和辅助技术体验正确。
故障响应需要角色、信息和复盘机制
临时群聊和个人经验会延长恢复时间并丢失关键证据。
技术文档要服务下一次修改和故障恢复
只描述安装步骤，无法解释系统边界和关键取舍。
企业网站技术选型，先看五年维护成本
框架是否流行不是唯一标准，团队能力、内容频率与部署环境更影响长期结果。