简介这份资源是面向iOS开发初学者与进阶者的NSData实战源码包聚焦Objective-C中Foundation框架核心类NSData的数据处理能力。内容围绕二进制数据存储、文件读写、JSON序列化与归档、Base64编码、AES加密、网络请求体封装及图片数据转换等典型场景展开帮助开发者解决数据持久化、网络通信与安全传输中的实际问题。压缩包共6个文件约9KB包含main.m源码、NSData_Prefix.pch预编译头、NSData-Info.plist配置文件以及Xcode工程相关文件结构精简便于直接导入工程运行调试。目前已有280人学习下载适合希望深入理解NSData用法、补齐数据处理短板的iOS开发者参考实践。1. 从一份 NSData 源码包说起iOS 二进制数据处理的起点很多人第一次接触 iOS 数据持久化都是从NSString写 plist 开始的直到某天遇到一个需求把一张图片的原始字节流塞进本地缓存、或者把一段 protobuf 序列化后的 buffer 直接落盘。这时候NSString就不够用了必须请出NSData。我手上这份名为NSData.rar的 iOS 应用源码包就是围绕这个基础类展开的一组可运行示例。它包含NSData Classes、NSData_Prefix.pch、NSData-Info.plist、main.m、build目录以及NSData.xcodeproj工程文件是一套结构完整的 Objective-C 工程。适合正在补 iOS 底层数据操作这一课的新手也适合想回头梳理NSData边界行为的老手。下面我按“它是什么、怎么跑起来、坑在哪、还能怎么用”的顺序拆一遍。2. 拆开 NSData.xcodeproj工程结构与 NSData 核心 API 的对应关系2.1 从文件清单看这份源码的组织方式拿到一个.xcodeproj工程我习惯先看目录结构再动手编译因为文件命名往往直接暴露了作者的意图。这份源码包的文件清单不长但每个文件都对应 iOS 工程的一个标准角色文件/目录角色与 NSData 的关联NSData.xcodeprojXcode 工程文件管理编译目标、Build Phase、依赖NSData Classes源码目录存放 NSData 相关示例类实现NSData_Prefix.pch预编译头全局引入 Foundation省去重复 importNSData-Info.plist应用配置声明 Bundle 信息、入口类main.m程序入口创建 autoreleasepool调用示例逻辑build编译产物目录存放中间文件与可执行产物project.pbxproj工程描述记录文件引用、编译参数henryyu.mode1v3/henryyu.pbxuser用户界面状态记录窗口布局、断点等本地状态NSData_Prefix.pch这个文件值得单独说一句。在早期 Objective-C 工程里.pch是标配它会在每个源文件编译前自动插入通常用来放#import Foundation/Foundation.h和#import UIKit/UIKit.h。这意味着NSData Classes里的实现文件不需要再手动引入 Foundation 就能直接用NSData、NSMutableData这些类型。如果你把这份源码迁移到较新的 Xcode 工程.pch默认不再自动生成需要手动在 Build Settings 的Prefix Header里指定路径否则会报一堆“use of undeclared identifier”的错。henryyu.mode1v3和henryyu.pbxuser是 Xcode 的用户级状态文件记录的是某位开发者本地的窗口布局和断点跟代码逻辑无关。这两个文件在团队协作时通常应该加入.gitignore因为它们会随个人操作频繁变动提交上去只会制造无意义的 diff。看到这两个文件基本可以判断这份源码是从某个开发者的本地工作目录直接打包出来的保留了原始的开发痕迹。2.2 NSData 的创建、读写与转换把 API 落到代码上NSData是不可变类NSMutableData是它的可变子类。这份源码的核心价值在于把NSData的几类典型用法串了起来。我按自己的理解重新组织一遍方便你对照源码看。从字节缓冲区创建。最底层的方式是直接给指针和长度// 从 C 数组创建 NSDatalength 必须准确否则会读到越界内存 const char bytes[] {0x48, 0x65, 0x6C, 0x6C, 0x6F}; NSData *data [NSData dataWithBytes:bytes length:sizeof(bytes)]; NSLog(length %lu, (unsigned long)data.length); // 输出 5这里length参数是字节数不是字符数。sizeof(bytes)对char数组来说恰好等于字节数但如果换成int数组就会翻四倍这是新手最容易翻车的地方。我一般会显式写成sizeof(bytes) / sizeof(bytes[0]) * sizeof(int)这种形式来提醒自己单位。从文件读写。这是NSData在日常开发中出现频率最高的场景// 读从沙盒路径加载文件为 NSData NSString *path [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject]; NSString *filePath [path stringByAppendingPathComponent:cache.bin]; NSData *fileData [NSData dataWithContentsOfFile:filePath]; // 写atomically 为 YES 时先写临时文件再原子替换避免写入中断导致文件损坏 BOOL ok [fileData writeToFile:filePath atomically:YES]; if (!ok) { NSLog(写入失败检查目录是否存在、是否有写权限); }dataWithContentsOfFile:在文件不存在时返回nil不会抛异常所以调用后必须判空。writeToFile:atomically:的atomically参数我建议始终传YES代价是多一次临时文件写入换来的是掉电或崩溃时不会留下半截文件。编码转换。NSData和字符串之间的互转是另一个高频操作// NSData - NSString必须指定编码编码不匹配会返回 nil NSString *text iOS 数据操作; NSData *utf8Data [text dataUsingEncoding:NSUTF8StringEncoding]; NSString *decoded [[NSString alloc] initWithData:utf8Data encoding:NSUTF8StringEncoding]; // Base64 编码常用于把二进制数据塞进 JSON 或 URL NSString *base64 [utf8Data base64EncodedStringWithOptions:0]; NSData *restored [[NSData alloc] initWithBase64EncodedString:base64 options:0];initWithData:encoding:在字节序列不符合指定编码时返回nil不会崩溃但如果你不判空就直接用后面就是nil消息传递的玄学现场。Base64 的options参数传0表示不换行传NSDataBase64Encoding64CharacterLineLength会每 64 字符插入换行选哪个取决于接收方能不能处理换行符。2.3 编译与运行让这份老工程在新 Xcode 上跑起来这份源码用的是.xcodeproj工程格式main.m作为入口属于典型的命令行工具或早期单视图应用结构。直接双击打开大概率会遇到两个问题一是部署目标版本过低新 Xcode 不再支持二是.pch路径失效。我的处理步骤是这样的第一步用 Xcode 打开NSData.xcodeproj在 Project Navigator 里选中工程进入 Build Settings把iOS Deployment Target调到当前 Xcode 支持的最低版本以上。如果工程类型是命令行工具Deployment Target 可以设得更低因为不涉及模拟器运行。第二步检查Prefix Header设置。如果 Build Settings 里Prefix Header为空而源码里又依赖.pch中的 import就手动填入NSData_Prefix.pch的相对路径通常是NSData/NSData_Prefix.pch这种形式。路径写错会报file not found。第三步清理build目录。这份源码包里带了旧的build产物直接编译可能因为缓存不一致报奇怪的链接错误。在 Xcode 里执行Product Clean Build Folder或者手动删掉build目录再编译。第四步如果main.m里用的是NSAutoreleasePool而不是autoreleasepool说明代码年代较早。NSAutoreleasePool在 ARC 下不可用需要在 Build Settings 里确认Objective-C Automatic Reference Counting的开关状态。如果工程是 MRC 的保持关闭即可如果想迁移到 ARC需要把NSAutoreleasePool替换为autoreleasepool块。跑起来之后控制台会输出各示例的执行结果。我建议在main.m里逐段注释掉其他示例只保留一个这样输出干净方便对照源码理解每一步的数据变化。3. 避坑排查NSData 操作里那些让人半夜爬起来改代码的瞬间3.1 长度参数传错导致越界读取现象程序在模拟器上跑得好好的一到真机就随机崩溃崩溃栈指向dataWithBytes:length:附近。原因length传的是元素个数而不是字节数。比如源数据是int数组你传了sizeof(array)得到的是字节数但如果传的是array.count之类的逻辑长度就会少读或多读。更隐蔽的情况是传入了一个栈上的临时缓冲区指针NSData创建时拷贝了数据但如果length超过缓冲区实际大小拷贝阶段就已经越界了。解决创建NSData时length一律用sizeof或明确的字节数常量。如果数据来自网络或文件先用NSMutableData的appendBytes:length:逐段追加每段长度由数据源保证。真机崩溃而模拟器不崩往往是因为模拟器内存布局宽松越界没触发保护这种问题必须靠代码审查而不是靠测试发现。3.2 文件路径拼接漏掉目录导致写入失败现象writeToFile:atomically:返回NO但控制台没有任何错误信息。原因NSData的写入方法不会自动创建中间目录。如果你拼的路径是Documents/subdir/cache.bin而subdir不存在写入直接失败。另一个常见原因是路径里用了~或相对路径iOS 沙盒环境下这些都不成立。解决写入前用NSFileManager的createDirectoryAtPath:withIntermediateDirectories:YES attributes:nil error:确保目录存在。路径一律用NSSearchPathForDirectoriesInDomains获取沙盒根再stringByAppendingPathComponent:逐级拼接不要手动拼/。写入失败时把filePath打印出来对照沙盒实际路径排查。3.3 编码不匹配导致字符串转换返回 nil现象从网络拿到的NSData转NSString后是nil但数据明明有内容。原因服务端返回的是 GBK 编码客户端用NSUTF8StringEncoding解码字节序列不合法initWithData:encoding:直接返回nil。还有一种情况是数据头部带了 BOMUTF-8 BOM 的三个字节EF BB BF会让部分解码器判断失误。解决先确认数据源编码。如果服务端可控统一用 UTF-8。如果不可控用NSStringEncodingDetection或尝试多种编码先试 UTF-8失败再试NSASCIIStringEncoding或CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingGB_18030_2000)。转换后必须判空nil时走降级逻辑而不是直接使用。3.4 Base64 编码选项不一致导致解码失败现象自己编码的 Base64 字符串自己解码却得到nil或乱码。原因编码时用了NSDataBase64Encoding64CharacterLineLength插入了换行解码时没有忽略未知字符或者解码时用了不同的options。Base64 标准本身对换行的处理就有分歧有的实现要求忽略换行有的要求严格匹配。解决编解码两端约定统一的options。如果数据要放进 JSON 或 URL编码时传0不换行解码时传NSDataBase64DecodingIgnoreUnknownCharacters提高容错。跨语言场景下先拿一个短字符串做往返测试确认两端行为一致再上真实数据。3.5 大文件一次性加载导致内存峰值过高现象加载一个几十兆的文件时App 内存曲线陡增在低端设备上被系统杀掉。原因dataWithContentsOfFile:会把整个文件读进内存文件多大就占多大内存再加上后续转换操作可能产生副本峰值是文件大小的两到三倍。解决大文件用NSFileHandle分块读取或者用NSData的dataWithContentsOfFile:options:NSDataReadingMappedIfSafe做内存映射让系统按需分页加载。如果只是要把文件从 A 拷到 B用NSFileManager的copyItemAtPath:toPath:error:根本不需要经过NSData。这份源码里的示例数据量小不会触发这个问题但把代码用到真实项目时数据量一上来就要换方案。4. 进阶用法从 NSData 到 NSMutableData 的拼接与序列化实战4.1 用 NSMutableData 做增量拼接NSData不可变每次“修改”都是创建新对象。需要频繁追加数据的场景比如接收分片网络响应、逐段解析二进制协议应该用NSMutableDataNSMutableData *buffer [NSMutableData data]; // 模拟分三次收到数据片段 for (int i 0; i 3; i) { const char *chunk [[NSString stringWithFormat:chunk%d, i] UTF8String]; [buffer appendBytes:chunk length:strlen(chunk)]; } NSLog(total length %lu, (unsigned long)buffer.length); // 拼接完成后可以转为不可变 NSData 传给其他 API NSData *finalData [buffer copy];appendBytes:length:的length同样必须是字节数。strlen对 C 字符串有效但对含\0的二进制数据会提前截断那种情况必须用已知长度而不是strlen。拼接完成后用copy转成NSData避免后续误改。4.2 归档与 JSON 序列化中的 NSData 角色NSKeyedArchiver归档对象时最终产物就是NSData。反归档时从NSData还原对象// 归档对象图 - NSData NSDictionary *dict {key: value, num: (42)}; NSData *archived [NSKeyedArchiver archivedDataWithRootObject:dict requiringSecureCoding:NO error:nil]; // 反归档NSData - 对象图 id restored [NSKeyedUnarchiver unarchiveObjectWithData:archived]; NSLog(restored %, restored);requiringSecureCoding参数在新版本 SDK 里建议传YES并配合NSSecureCoding协议传NO会有安全警告。JSON 序列化同理NSJSONSerialization的输入输出都是NSData中间不经过字符串避免编码转换损耗。4.3 一个验证习惯我每次写完涉及NSData的代码都会在关键节点加一行长度和首字节的日志NSLog(data length%lu firstByte0x%02X, (unsigned long)data.length, data.length 0 ? ((const unsigned char *)data.bytes)[0] : 0);长度对不上说明创建或拼接阶段就错了首字节不对说明数据源或偏移量有问题。这行日志帮我省过很多次逐行调试的时间。从那以后凡是碰二进制数据我都强制走一遍“长度 首字节”的检查确认无误再往下写业务逻辑。希望这份源码包能帮你把NSData这一块彻底跑通少走一些我当年走过的弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 12:45:07 · 阅读 1.2k iOS NSData 源码实战：二进制数据处理与避坑指南
简介这份资源是面向iOS开发初学者与进阶者的NSData实战源码包聚焦Objective-C中Foundation框架核心类NSData的数据处理能力。内容围绕二进制数据存储、文件读写、JSON序列化与归档、Base64编码、AES加密、网络请求体封装及图片数据转换等典型场景展开帮助开发者解决数据持久化、网络通信与安全传输中的实际问题。压缩包共6个文件约9KB包含main.m源码、NSData_Prefix.pch预编译头、NSData-Info.plist配置文件以及Xcode工程相关文件结构精简便于直接导入工程运行调试。目前已有280人学习下载适合希望深入理解NSData用法、补齐数据处理短板的iOS开发者参考实践。1. 从一份 NSData 源码包说起iOS 二进制数据处理的起点很多人第一次接触 iOS 数据持久化都是从NSString写 plist 开始的直到某天遇到一个需求把一张图片的原始字节流塞进本地缓存、或者把一段 protobuf 序列化后的 buffer 直接落盘。这时候NSString就不够用了必须请出NSData。我手上这份名为NSData.rar的 iOS 应用源码包就是围绕这个基础类展开的一组可运行示例。它包含NSData Classes、NSData_Prefix.pch、NSData-Info.plist、main.m、build目录以及NSData.xcodeproj工程文件是一套结构完整的 Objective-C 工程。适合正在补 iOS 底层数据操作这一课的新手也适合想回头梳理NSData边界行为的老手。下面我按“它是什么、怎么跑起来、坑在哪、还能怎么用”的顺序拆一遍。2. 拆开 NSData.xcodeproj工程结构与 NSData 核心 API 的对应关系2.1 从文件清单看这份源码的组织方式拿到一个.xcodeproj工程我习惯先看目录结构再动手编译因为文件命名往往直接暴露了作者的意图。这份源码包的文件清单不长但每个文件都对应 iOS 工程的一个标准角色文件/目录角色与 NSData 的关联NSData.xcodeprojXcode 工程文件管理编译目标、Build Phase、依赖NSData Classes源码目录存放 NSData 相关示例类实现NSData_Prefix.pch预编译头全局引入 Foundation省去重复 importNSData-Info.plist应用配置声明 Bundle 信息、入口类main.m程序入口创建 autoreleasepool调用示例逻辑build编译产物目录存放中间文件与可执行产物project.pbxproj工程描述记录文件引用、编译参数henryyu.mode1v3/henryyu.pbxuser用户界面状态记录窗口布局、断点等本地状态NSData_Prefix.pch这个文件值得单独说一句。在早期 Objective-C 工程里.pch是标配它会在每个源文件编译前自动插入通常用来放#import Foundation/Foundation.h和#import UIKit/UIKit.h。这意味着NSData Classes里的实现文件不需要再手动引入 Foundation 就能直接用NSData、NSMutableData这些类型。如果你把这份源码迁移到较新的 Xcode 工程.pch默认不再自动生成需要手动在 Build Settings 的Prefix Header里指定路径否则会报一堆“use of undeclared identifier”的错。henryyu.mode1v3和henryyu.pbxuser是 Xcode 的用户级状态文件记录的是某位开发者本地的窗口布局和断点跟代码逻辑无关。这两个文件在团队协作时通常应该加入.gitignore因为它们会随个人操作频繁变动提交上去只会制造无意义的 diff。看到这两个文件基本可以判断这份源码是从某个开发者的本地工作目录直接打包出来的保留了原始的开发痕迹。2.2 NSData 的创建、读写与转换把 API 落到代码上NSData是不可变类NSMutableData是它的可变子类。这份源码的核心价值在于把NSData的几类典型用法串了起来。我按自己的理解重新组织一遍方便你对照源码看。从字节缓冲区创建。最底层的方式是直接给指针和长度// 从 C 数组创建 NSDatalength 必须准确否则会读到越界内存 const char bytes[] {0x48, 0x65, 0x6C, 0x6C, 0x6F}; NSData *data [NSData dataWithBytes:bytes length:sizeof(bytes)]; NSLog(length %lu, (unsigned long)data.length); // 输出 5这里length参数是字节数不是字符数。sizeof(bytes)对char数组来说恰好等于字节数但如果换成int数组就会翻四倍这是新手最容易翻车的地方。我一般会显式写成sizeof(bytes) / sizeof(bytes[0]) * sizeof(int)这种形式来提醒自己单位。从文件读写。这是NSData在日常开发中出现频率最高的场景// 读从沙盒路径加载文件为 NSData NSString *path [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject]; NSString *filePath [path stringByAppendingPathComponent:cache.bin]; NSData *fileData [NSData dataWithContentsOfFile:filePath]; // 写atomically 为 YES 时先写临时文件再原子替换避免写入中断导致文件损坏 BOOL ok [fileData writeToFile:filePath atomically:YES]; if (!ok) { NSLog(写入失败检查目录是否存在、是否有写权限); }dataWithContentsOfFile:在文件不存在时返回nil不会抛异常所以调用后必须判空。writeToFile:atomically:的atomically参数我建议始终传YES代价是多一次临时文件写入换来的是掉电或崩溃时不会留下半截文件。编码转换。NSData和字符串之间的互转是另一个高频操作// NSData - NSString必须指定编码编码不匹配会返回 nil NSString *text iOS 数据操作; NSData *utf8Data [text dataUsingEncoding:NSUTF8StringEncoding]; NSString *decoded [[NSString alloc] initWithData:utf8Data encoding:NSUTF8StringEncoding]; // Base64 编码常用于把二进制数据塞进 JSON 或 URL NSString *base64 [utf8Data base64EncodedStringWithOptions:0]; NSData *restored [[NSData alloc] initWithBase64EncodedString:base64 options:0];initWithData:encoding:在字节序列不符合指定编码时返回nil不会崩溃但如果你不判空就直接用后面就是nil消息传递的玄学现场。Base64 的options参数传0表示不换行传NSDataBase64Encoding64CharacterLineLength会每 64 字符插入换行选哪个取决于接收方能不能处理换行符。2.3 编译与运行让这份老工程在新 Xcode 上跑起来这份源码用的是.xcodeproj工程格式main.m作为入口属于典型的命令行工具或早期单视图应用结构。直接双击打开大概率会遇到两个问题一是部署目标版本过低新 Xcode 不再支持二是.pch路径失效。我的处理步骤是这样的第一步用 Xcode 打开NSData.xcodeproj在 Project Navigator 里选中工程进入 Build Settings把iOS Deployment Target调到当前 Xcode 支持的最低版本以上。如果工程类型是命令行工具Deployment Target 可以设得更低因为不涉及模拟器运行。第二步检查Prefix Header设置。如果 Build Settings 里Prefix Header为空而源码里又依赖.pch中的 import就手动填入NSData_Prefix.pch的相对路径通常是NSData/NSData_Prefix.pch这种形式。路径写错会报file not found。第三步清理build目录。这份源码包里带了旧的build产物直接编译可能因为缓存不一致报奇怪的链接错误。在 Xcode 里执行Product Clean Build Folder或者手动删掉build目录再编译。第四步如果main.m里用的是NSAutoreleasePool而不是autoreleasepool说明代码年代较早。NSAutoreleasePool在 ARC 下不可用需要在 Build Settings 里确认Objective-C Automatic Reference Counting的开关状态。如果工程是 MRC 的保持关闭即可如果想迁移到 ARC需要把NSAutoreleasePool替换为autoreleasepool块。跑起来之后控制台会输出各示例的执行结果。我建议在main.m里逐段注释掉其他示例只保留一个这样输出干净方便对照源码理解每一步的数据变化。3. 避坑排查NSData 操作里那些让人半夜爬起来改代码的瞬间3.1 长度参数传错导致越界读取现象程序在模拟器上跑得好好的一到真机就随机崩溃崩溃栈指向dataWithBytes:length:附近。原因length传的是元素个数而不是字节数。比如源数据是int数组你传了sizeof(array)得到的是字节数但如果传的是array.count之类的逻辑长度就会少读或多读。更隐蔽的情况是传入了一个栈上的临时缓冲区指针NSData创建时拷贝了数据但如果length超过缓冲区实际大小拷贝阶段就已经越界了。解决创建NSData时length一律用sizeof或明确的字节数常量。如果数据来自网络或文件先用NSMutableData的appendBytes:length:逐段追加每段长度由数据源保证。真机崩溃而模拟器不崩往往是因为模拟器内存布局宽松越界没触发保护这种问题必须靠代码审查而不是靠测试发现。3.2 文件路径拼接漏掉目录导致写入失败现象writeToFile:atomically:返回NO但控制台没有任何错误信息。原因NSData的写入方法不会自动创建中间目录。如果你拼的路径是Documents/subdir/cache.bin而subdir不存在写入直接失败。另一个常见原因是路径里用了~或相对路径iOS 沙盒环境下这些都不成立。解决写入前用NSFileManager的createDirectoryAtPath:withIntermediateDirectories:YES attributes:nil error:确保目录存在。路径一律用NSSearchPathForDirectoriesInDomains获取沙盒根再stringByAppendingPathComponent:逐级拼接不要手动拼/。写入失败时把filePath打印出来对照沙盒实际路径排查。3.3 编码不匹配导致字符串转换返回 nil现象从网络拿到的NSData转NSString后是nil但数据明明有内容。原因服务端返回的是 GBK 编码客户端用NSUTF8StringEncoding解码字节序列不合法initWithData:encoding:直接返回nil。还有一种情况是数据头部带了 BOMUTF-8 BOM 的三个字节EF BB BF会让部分解码器判断失误。解决先确认数据源编码。如果服务端可控统一用 UTF-8。如果不可控用NSStringEncodingDetection或尝试多种编码先试 UTF-8失败再试NSASCIIStringEncoding或CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingGB_18030_2000)。转换后必须判空nil时走降级逻辑而不是直接使用。3.4 Base64 编码选项不一致导致解码失败现象自己编码的 Base64 字符串自己解码却得到nil或乱码。原因编码时用了NSDataBase64Encoding64CharacterLineLength插入了换行解码时没有忽略未知字符或者解码时用了不同的options。Base64 标准本身对换行的处理就有分歧有的实现要求忽略换行有的要求严格匹配。解决编解码两端约定统一的options。如果数据要放进 JSON 或 URL编码时传0不换行解码时传NSDataBase64DecodingIgnoreUnknownCharacters提高容错。跨语言场景下先拿一个短字符串做往返测试确认两端行为一致再上真实数据。3.5 大文件一次性加载导致内存峰值过高现象加载一个几十兆的文件时App 内存曲线陡增在低端设备上被系统杀掉。原因dataWithContentsOfFile:会把整个文件读进内存文件多大就占多大内存再加上后续转换操作可能产生副本峰值是文件大小的两到三倍。解决大文件用NSFileHandle分块读取或者用NSData的dataWithContentsOfFile:options:NSDataReadingMappedIfSafe做内存映射让系统按需分页加载。如果只是要把文件从 A 拷到 B用NSFileManager的copyItemAtPath:toPath:error:根本不需要经过NSData。这份源码里的示例数据量小不会触发这个问题但把代码用到真实项目时数据量一上来就要换方案。4. 进阶用法从 NSData 到 NSMutableData 的拼接与序列化实战4.1 用 NSMutableData 做增量拼接NSData不可变每次“修改”都是创建新对象。需要频繁追加数据的场景比如接收分片网络响应、逐段解析二进制协议应该用NSMutableDataNSMutableData *buffer [NSMutableData data]; // 模拟分三次收到数据片段 for (int i 0; i 3; i) { const char *chunk [[NSString stringWithFormat:chunk%d, i] UTF8String]; [buffer appendBytes:chunk length:strlen(chunk)]; } NSLog(total length %lu, (unsigned long)buffer.length); // 拼接完成后可以转为不可变 NSData 传给其他 API NSData *finalData [buffer copy];appendBytes:length:的length同样必须是字节数。strlen对 C 字符串有效但对含\0的二进制数据会提前截断那种情况必须用已知长度而不是strlen。拼接完成后用copy转成NSData避免后续误改。4.2 归档与 JSON 序列化中的 NSData 角色NSKeyedArchiver归档对象时最终产物就是NSData。反归档时从NSData还原对象// 归档对象图 - NSData NSDictionary *dict {key: value, num: (42)}; NSData *archived [NSKeyedArchiver archivedDataWithRootObject:dict requiringSecureCoding:NO error:nil]; // 反归档NSData - 对象图 id restored [NSKeyedUnarchiver unarchiveObjectWithData:archived]; NSLog(restored %, restored);requiringSecureCoding参数在新版本 SDK 里建议传YES并配合NSSecureCoding协议传NO会有安全警告。JSON 序列化同理NSJSONSerialization的输入输出都是NSData中间不经过字符串避免编码转换损耗。4.3 一个验证习惯我每次写完涉及NSData的代码都会在关键节点加一行长度和首字节的日志NSLog(data length%lu firstByte0x%02X, (unsigned long)data.length, data.length 0 ? ((const unsigned char *)data.bytes)[0] : 0);长度对不上说明创建或拼接阶段就错了首字节不对说明数据源或偏移量有问题。这行日志帮我省过很多次逐行调试的时间。从那以后凡是碰二进制数据我都强制走一遍“长度 首字节”的检查确认无误再往下写业务逻辑。希望这份源码包能帮你把NSData这一块彻底跑通少走一些我当年走过的弯路。本文还有配套的精品资源点击获取