向SQL数据库存储<img>时能否用标识符替代实际图片？

完全可以实现你要的效果，不需要每次存储用户拼接完成的整图，核心思路是把固定卡片资源和用户排布数据拆分存储，只需要传标识就能完成后续渲染，具体落地方式如下：

第一步：预托管固定卡片资源 #

• 把所有支持用户拖拽的预置卡片图片，统一上传到你自己的静态资源服务/站点存储目录，给每一张卡片分配全局唯一的固定ID作为标识，比如card_001_redbuff_start、card_023_mid_roam这类字符串ID
• 本地维护一份卡片ID和图片资源路径的固定映射表，比如card_001_redbuff_start对应资源路径/static/game-cards/card_001_redbuff_start.png，这份映射表不需要随用户攻略数据存储，前端渲染时直接读取即可

第二步：用户提交时仅传输结构化标识数据 #

用户完成拖拽、填完辅助说明点击提交时，不需要上传拼接好的完整攻略图，只需要传输类似下面结构的结构化数据即可，数据直接存入SQL数据库：

{
  "guide_name": "打野3分钟速4开局路线",
  "slot_list": [
    {
      "slot_index": 1,
      "card_id": "card_001_redbuff_start",
      "tip_text": "1分30秒准时打红，留第一个惩戒",
      "sort_order": 1
    },
    {
      "slot_index": 2,
      "card_id": "card_012_krug_camp",
      "tip_text": "红打完刷石甲虫，交惩戒提速",
      "sort_order": 2
    }
  ],
  "extra_desc": "这套路线适合对位前期弱势打野的对局"
}

这种存储方案比存整图实用性高很多：单条攻略数据大小通常只有几KB，远小于几MB的整图，还支持直接按卡片ID检索相关攻略，后续用户编辑攻略也不需要重新上传拼接图片，只需要修改对应槽位的卡片ID和备注文本即可。

第三步：详情页按标识还原渲染 #

• 用户打开攻略独立展示页时，后端直接把对应攻略的结构化数据返回给前端
• 前端遍历槽位列表，根据每个槽位存储的card_id，从预置的卡片映射表中拿到对应图片地址，按照存储的排序、槽位位置把图片渲染到页面指定区域，再把对应辅助说明文本拼接在卡片对应位置即可，渲染效果和用户编辑时看到的排布完全一致

可选优化点 #

• 如果后续会迭代卡片素材，可以给每张卡片增加版本号字段，历史攻略引用的旧版本卡片资源单独归档存储，避免素材更新导致旧攻略显示错乱
• 如果支持用户上传自定义拖拽卡片，逻辑和预置卡片完全一致：用户上传自定义图片后，系统给这张图分配唯一的自定义卡片ID，存好对应资源路径，后续渲染逻辑和预置卡片无区别
• 如果需要生成攻略分享长图，不需要提前存储生成好的图片，用户点击分享时前端实时按照排布规则拼接生成图片即可，不占用长期存储空间

内容的提问来源于stack exchange，提问作者alikmetalik