接手商城先查什么

接手商城为什么先建立证据清单？

现有系统能登录，只能证明某个运行入口当前可用。源码能否构建、运行产物来自哪里、客户是否掌握配置和恢复资料，都需要单独核对。接手工作先确认合法授权和环境归属，再建立只读证据，避免在不了解现场的情况下升级依赖、重建数据库或替换原程序。

技术体检包含源码与部署检查，也检查客户团队的改动，详见技术体检服务。实际实施要看源码、资料、许可和业务条件。无法取得关键材料时说明限制，仍可完成不依赖它的检查，但不能把缺少证据的部分写成已恢复或已接管。

源码、提交号和运行产物怎样关联？

核对仓库历史、当前分支、未提交修改和构建入口，确认哪些目录是源码、依赖、产物或持久资料。服务器上的文件未必与客户交来的压缩包一致，版本说明也可能只记录打包时间。需要通过构建日志、文件校验和运行记录建立关联，不能只靠文件修改日期判断。

资料对象	只读核对内容	还不能证明的结果
源码仓库	历史、分支、修改和缺失文件	当前运行程序一定来自该版本
构建资料	工具链、锁文件、私有依赖和日志	客户环境可以直接重建
程序产物	文件校验、版本、架构和运行入口	所有业务流程已验收
数据结构	迁移历史、角色和当前对象	历史资料都能正确解释
运行配置	来源、归属和保管方式	配置已获授权且仍有效
外部协作	商户主体、接口版本和资料负责方	实际生产渠道已经联调通过

将关联不清的项目标为待查，不为了填满清单临时生成新的版本标签。后续若需要隔离构建，应保留原材料并记录输入与结果，不修改共享工作区来迁就构建错误。重建失败的原因也属于有价值的接手证据。

配置和保护钥匙应由谁提供？

客户应明确哪些资源由自己持有，哪些由原供应商保管，哪些需要渠道授权。秘密资料通过受控方式取得，审查报告只记位置、权限和校验状态，不复制真实值。共享账号、浏览器Cookie和个人设备里的备份不能自动视为可长期使用的企业资料。

保护钥匙可能关联已有密文，不能因接管而统一生成新值。先核对用途、恢复需要和轮换条件，再决定处理方式。没有合法资料时，不能直接改库绕过认证或使用原开发者会话继续操作；正常身份与权限链需要通过获授权的账号验证。

应该先看哪些业务链路？

从客户最担心的风险选择路径：商品如何发布、订单如何成交、付款怎样确认、发货怎样协作、售后如何处理。每条路径记录角色、业务对象和状态，确认页面显示与后端资料一致。后台列表能够读取，不代表消费者端流程和外部渠道已经完整成立。

使用合成或获授权的脱敏资料，优先只读核对已有结果。需要写入验证时事先限定环境、资料和资金，说明回收方法。不能在真实环境随意重复付款、退款或发货，也不能把历史订单重放当作无风险测试。未知结果通过业务编号查询后再决定下一步。

数据库检查怎样避免误伤现有业务？

先查看结构版本、角色范围、数据归属和业务关联，不直接执行修复SQL。发现异常时记录查询口径、条件、数量和代表性对象，区分展示问题、统计问题和源记录问题。某个报表与业务不一致，可能由任务、缓存或不同历史口径引起，不能直接覆盖统计结果掩盖原因。

BoolMall当前迁移约束可核对：迁移资源归所属业务域，包含 SQL 与 Java Flyway 迁移；已发布迁移字节及 Java identity/checksum 需要保留，运行与迁移角色分开。 对其他来源系统则需按其实际机制审查，不能把BoolMall的迁移工具套到未知库。涉及资料搬迁时建立映射和对账规则，确认历史金额、状态及附件的解释，参考迁移专题组织后续工作。

怎样判断接口与权限的隐藏风险？

列出公开、管理、消费者和外部回调入口，核对身份、请求方法、权限和对象范围。某个管理页面没有按钮，并不能证明接口拒绝访问；某个接口返回成功，也不能证明敏感字段经过正确过滤。检查应包含允许与拒绝、同范围与跨范围的真实用例。

对于BoolMall自身能够核对的部分：单体版存在账号类型声明、权限目录和业务审计声明；检查授权需同时核对请求方法、主体权限与业务数据范围。 这只是特定源码版本的实现事实。接手其他系统时须重新找证据，并确认实际部署版本没有绕过或修改检查链。审查结论应指明测试对象与条件，不笼统宣称整个系统安全。

恢复资料怎样在隔离环境核验？

先建立与原环境分开的目录、数据库和账号，检查备份格式、结构版本及必要保护资料。隔离恢复后核对关键业务资料、附件和查询，不用恢复命令退出码代替结果。若只能恢复数据库但缺少程序或密钥，应明确写成部分恢复，不能称完整系统已可运行。

原环境与原始备份保持不变，测试副本的归属和清理范围要记录。依赖原网络或外部账号时，判断是否会向真实客户发通知或调用真实渠道，必要时采用明确的隔离配置。恢复与验收的边界也应交给业务方，让他们知道哪些问题仍可能影响切换。

如何分出必须先处理和可以后续处理的问题？

按业务影响和证据分类。关键资料缺失、不可解释付款、无恢复路径或越权访问，可能阻止正式接管；文档缺少索引或局部代码重复则可进入后续计划。不能把所有问题都写成立即重写的理由，也不能为了尽快接单忽略高影响缺口。

每个问题列现象、依据、受影响范围、下一步与负责方。对尚未确定原因的故障，用可验证假设继续调查，避免仅凭框架版本或代码风格下结论。计划中区分现状修复、范围变化和架构改造，让客户能够逐步检查确认。

审查结束后怎样逐步接管？

先交付资料索引、版本关联、业务路径、问题清单和恢复边界。运行权限按岗位逐步转移，由接班人实际执行获授权的查询和状态检查；临时权限完成用途后回收。接管某个环节时说明生效时间与责任，避免原供应商和新团队同时修改同一环境。

用商城选型对比表整理当前条件，与技术体检服务确认审查范围，再回到二开专题安排定制与升级。接手结论应由实际证据支撑。

原始资料怎样防止在审查中丢失？

原包、原始备份和原环境保持独立归档，记录取得方式与校验依据。调查使用自有副本，修改前后分别保存结果；不能为了让工具运行而覆盖客户统一材料。清理只针对已确认归属的临时输出，并保留仍需恢复或复查的资料，避免把审查过程本身变成新的恢复风险。