向Repository传入端点字符串是否为反模式？有何替代方案？

直接给结论：你考虑的方案2属于仓储模式的典型反模式，并不符合设计规范，问题核心不是“传endpoint”这个动作本身，而是这种写法彻底违背了仓储模式的设计初衷。

为什么传入endpoint的通用仓储是反模式 #

仓储模式的核心职责，是向上对业务层屏蔽所有数据获取的底层细节，提供和业务语义对齐的数据访问入口，让业务层不需要关心数据是来自接口、本地数据库还是缓存。把endpoint作为构造参数传入的写法，有三个绕不开的问题：

• 底层细节完全泄露给调用方。业务代码实例化仓储时必须硬编码接口路径，等于把本该被仓储封装的接口地址信息暴露到了业务层，后续如果后端调整接口路径、更换数据来源，你需要修改所有实例化该仓储的业务代码，完全失去了仓储层隔离变化的作用。
• 扩展性极差。你现在觉得两个场景逻辑完全一致，只是路径不同，只是当前阶段的暂时状态。后续如果热门Foo需要加本地缓存、最新Foo需要支持按时间范围过滤、热门列表需要做降级兜底，你只能给这个通用仓储不断加开关参数，最后类里塞满互斥的逻辑分支，变成没人敢改的上帝类。
• 完全失去类型安全。做依赖注入时，你没法靠类型区分不同场景的仓储实例，只能靠参数约定识别，但凡有人手滑传错了endpoint字符串，编译期完全无法发现问题，线上直接触发故障。

更合理的实现方式 #

你觉得两个独立仓储类会有重复代码，本质是抽离通用逻辑的层级选错了——不要在仓储层做通用抽象，把真正重复的底层逻辑（HTTP请求发送、响应序列化、统一错误处理、日志打点）抽离成业务层无感知的基础数据访问组件即可，仓储层本身可以做得非常薄，几乎没有冗余代码。

参考实现结构如下：

1. 先定义内部使用的基础API客户端，封装所有通用请求逻辑，不暴露给业务层

// 仅数据层内部使用，业务层不直接依赖
internal class FooApiClient(private val httpClient: HttpClient) {
    suspend fun requestFooList(path: String): List<Foo> {
        // 统一处理请求发起、JSON解析、错误码拦截、日志埋点等通用逻辑
    }
}

2. 定义和业务语义对齐的仓储实现，每个场景对应一个独立的仓储类，依赖上面的基础客户端

interface FooRepository {
    suspend fun getList(): List<Foo>
}

// 热门Foo仓储
class TrendingFoosRepository(
    private val apiClient: FooApiClient
) : FooRepository {
    override suspend fun getList(): List<Foo> {
        // 端点路径作为类内部的常量，完全不对外暴露
        return apiClient.requestFooList("/foos/trending")
    }
}

// 最新Foo仓储
class RecentFoosRepository(
    private val apiClient: FooApiClient
) : FooRepository {
    override suspend fun getList(): List<Foo> {
        return apiClient.requestFooList("/foos/recent")
    }
}

这种实现的优势非常明显：

• 业务层只需要依赖对应语义的仓储实例，完全不需要知道底层接口地址、数据来源等细节，后续数据层调整只需要修改对应仓储的内部实现，业务代码零改动
• 每个仓储的逻辑完全独立，后续需要给单个场景加专属逻辑（比如缓存、降级、特殊参数处理）时，直接修改对应仓储类即可，不会影响其他场景
• 依赖注入时可以靠类型精准匹配实例，不存在传错参数的风险，编译期即可发现依赖错误
• 没有多余的代码重复：所有通用的请求逻辑都收敛在基础客户端里，每个仓储类只有几行语义明确的代码，维护成本极低

不要为了少写几行样板代码打破架构边界：仓储的核心价值从来不是“复用请求逻辑”，而是“给业务层提供稳定的、语义明确的领域数据访问入口”。直接传endpoint的写法本质是把仓储降级成了HTTP客户端的简单包装，彻底丢掉了仓储层存在的意义。

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