针对特定用户混淆数据库列的设计模式选型咨询

核心设计框架 #

既然是类Proxy但接口不一致的场景，用组合式包装+定向拦截的思路最贴合需求，核心是做一个带混淆能力的包装类，既复用原有数据库访问逻辑，又能精准对特定用户触发混淆操作。

1. 基础类结构实现 #

先明确几个核心组件：

• 原始数据访问类：负责直接和数据库交互，返回原始数据，不用做任何修改
• 混淆包装类：持有原始数据访问类的实例，内置用户判定逻辑和混淆方法，对外暴露和原有数据访问类一致的查询入口（同时单独保留scramble方法供扩展）

伪代码示例：

# 原有数据库访问类（无需修改）
class RealDataFetcher:
    def get_user_record(self, user_id: str):
        # 实际数据库查询逻辑，返回原始记录
        return db.execute("SELECT * FROM users WHERE id = %s", (user_id,)).fetchone()

# 带混淆功能的包装类
class ScramblingDataWrapper:
    def __init__(self, real_fetcher: RealDataFetcher, target_users: set[str]):
        self.real_fetcher = real_fetcher
        self.target_users = target_users  # 特定用户集合（比如ID白名单、角色标识）

    def get_user_record(self, requester_id: str):
        # 先调用原始逻辑获取数据
        raw_record = self.real_fetcher.get_user_record(requester_id)
        # 判定当前请求用户是否需要混淆
        if requester_id in self.target_users:
            raw_record["sensitive_column"] = self.scramble_column(raw_record["sensitive_column"])
        return raw_record

    # 独立暴露的混淆方法
    def scramble_column(self, value: str) -> str:
        # 自定义混淆逻辑：比如掩码替换、哈希、随机脱敏等
        # 示例：手机号中间四位替换为****
        if len(value) == 11:
            return f"{value[:3]}****{value[-4:]}"
        return value

2. 适配接口不一致的优化方案 #

如果原有Web应用的数据库访问层没有统一接口，不用强行套Proxy的接口一致要求，直接用组合而非继承的方式：

• 包装类不需要实现原有数据访问类的接口，直接持有其实例
• 对外提供和原有类一致的方法签名，内部调用原有逻辑后追加混淆处理
• 这种方式完全规避接口不一致的问题，同时保持代码侵入性极低

3. 可扩展的进阶思路 #

• 抽离判定规则：把特定用户的判定逻辑拆成独立的UserChecker类，支持从配置文件、数据库动态加载规则（比如角色、权限组），不用修改包装类代码
• 多混淆策略：定义ScrambleStrategy接口，实现不同的混淆算法（比如哈希、掩码、随机替换），包装类根据配置动态选择策略，灵活应对不同列的脱敏需求
• 切面拦截实现：如果用Spring、Django等框架，也可以用AOP切面在数据返回的拦截点做定向混淆，这种方式不需要修改原有数据访问代码，更符合开闭原则

4. 关键注意点 #

• 混淆操作只作用于内存中的返回数据，绝对不能修改数据库原始数据，避免数据污染
• 混淆逻辑要轻量化，避免对查询性能造成过大影响；如果处理大量数据，可以考虑异步混淆或缓存脱敏结果
• 用户判定要和Web应用的权限体系强绑定，确保只有符合条件的用户才会触发混淆，防止越权

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