接手马甲包项目踩坑：全局配置的“硬编码”陷阱与YTKNetwork的正确用法

最近在接手离职同事的马甲包项目时，遇到了一些接口调用异常的问题。和后台联调后发现，请求明明发出去了，后台却始终拿不到预期的参数。

经过一番排查，最终定位到了底层网络库中的两处硬编码逻辑，导致部分接口的请求序列化方式和参数加密行为被错误覆盖。以下是问题代码的简化版：

[YTNetworkConfig sharedInstance].configRequestSerializerType = ^NSInteger(YTRequest *request) {
    // ❌ 硬编码：所有以 "post/" 开头的接口，GET 用 JSON 序列化，其他用 HTTP
    if ([request.pathUrl hasPrefix:@"post/"]) {
        return request.method == GET ? YTKRequestSerializerTypeJSON : YTKRequestSerializerTypeHTTP;
    }
    return YTKRequestSerializerTypeJSON;
};

[YTNetworkConfig sharedInstance].encryptParams = ^id(NSString *pathUrl, id params) {
    // ... 省略部分参数清理逻辑 ...
    
    // ❌ 硬编码：所有 "post/" 接口的参数被包装成 @{@"data": encryptStr}
    if ([pathUrl hasPrefix:@"post/"]) {
        return @{@"data": encryptStr};
    }
    return encryptStr;
};

这两段代码写得很“省事”，但却埋下了两个坑：

1. 所有符合 post/ 前缀的接口，不论实际需求，都被强制设定序列化方式；
2. 加密后的参数被硬性包装成 @{@"data": encryptStr} 结构，而其他接口却没有这个行为。

更讽刺的是，这类问题之所以一直没暴露，是因为后台同学“默默地”兼容了前端各种不规范传参——典型的 “基于Bug运行” 的代码。

如何正确处理？

其实，YTKNetwork 本身提供了非常清晰的接口个性化机制：通过继承 YTRequest 来实现不同接口的差异化配置。根本不需要在全局配置中写死特殊逻辑。

例如，我们可以为“心情卡片”接口创建一个专门的 MoodCardRequest 类：

// MoodCardRequest.h
@interface MoodCardRequest : YTRequest
@end

// MoodCardRequest.m
@implementation MoodCardRequest

- (YTKRequestSerializerType)requestSerializerType {
    // 明确指定使用 HTTP 序列化
    return YTKRequestSerializerTypeHTTP;
}

- (id)requestArgument {
    // 返回原始参数字典，无需加密包装
    return self.paramDict;
}

// ... 其他可选定制方法 ...
@end

这样做不仅结构清晰，也便于后续维护和扩展。

总结

• 尽量不要在全局配置中使用硬编码来做接口差异化，容易造成“误伤”；
• YTKNetwork 鼓励通过子类化 YTRequest 来实现不同接口的定制行为；
• 前后端约定应当明确，不能依赖对方的“兼容性”来掩盖设计问题。

这次排查虽然花了些时间，但也再次提醒我们：代码的清晰性和可维护性，远比一时的“方便”更重要。