分享AI、区块链技术及应用，未来已来

SQL报错1052因多表含同名列blocked_companies导致歧义，需用表别名明确指定列源。合并分支时，推荐使用Pull Request流程：先推送开发分支，创建MR，经代码审查后选择Squash and merge或Rebase and merge策略，确保主分支整洁安全。合并前务必git pull同步最新代码，保持工作区干净，避免直接在main分支修改。若误合并，未推送可用git reset --hard HEAD~1撤销；已推送则用git revert -m 1 <merge-commi

当Git因本地未提交修改与远端变更冲突而阻止git pull时，推荐优先使用路径一：暂存本地修改（git stash push），拉取后恢复（git stash pop），可安全保留工作成果。若确认无需本地修改，可用git reset --hard或git restore丢弃；若仅需单文件定向选择，使用git restore --ours/--theirs。预防关键：定期提交、善用pull --rebase、配置.gitattributes统一合并策略，减少冲突发生。

图形验证码“假刷新”问题源于浏览器缓存、HTTP策略与ServiceWorker多重叠加。在Vue中，通过在请求URL添加时间戳与随机参数实现唯一化，配合AbortController取消旧请求、Cache-Control: no-store禁用缓存，并在ServiceWorker中配置NetworkOnly，可彻底解决缓存劫持。结合响应式更新与对象URL管理，确保每次刷新均为新请求，无需提示用户清缓存。前端工程化改造需与后端响应头协同，根除验证码跨会话污染与重放风险。

能用代码“自愈”的，就不要把清缓存的操作转嫁给用户。版本哈希 + HTML 不缓存是基本盘，能覆盖绝大多数旧缓存导致的加载失败问题；Service Worker 自动清理旧缓存是加分项；只有在极端异常、上述机制均失效时，才考虑给出“点击刷新”或“清除缓存”的轻量提示作为兜底。

本文总结了防止重复提交的几种后端解决方案：1. Token令牌机制（推荐）：通过一次性Token验证请求唯一性，适用于核心业务场景。2. Redis幂等校验：利用SETNX命令实现高性能拦截，适合高并发场景。3. 分布式锁：解决多节点服务的并发问题。4. 数据库唯一约束：作为终极保障手段。5. 前端控制：辅助手段需配合后端方案。建议组合使用Redis快速拦截+数据库兜底+前端防抖，注意锁粒度、兜底方案和超时处理等常见问题。不同场景可选择不同方案组合，确保系统可靠性和用户体验。