iOS崩溃日志分析

最新推荐文章于 2025-08-03 11:04:13 发布
原创 最新推荐文章于 2025-08-03 11:04:13 发布 · 847 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#崩溃日志 #IOS

本文详细介绍了iOS应用在崩溃时如何生成和发送崩溃日志，包括通过手机发送文本、同步到电脑以及自动上传到iTC。同时解析了崩溃日志的格式，特别是异常类型、代码和线程信息，帮助开发者快速定位问题。

iOS崩溃日志分析

崩溃日志的产生

iOS中运行App过程中如果发生程序崩溃，会生成一个崩溃日志文件。这个文件会保存的特定系统目录下，扩展名是crash。你可以通过系统设置中的“通用-关于本机-诊断与用量-诊断与用量数据”来查看崩溃日志文件。

当手机连接到iTunes时，也会将该文件同步到电脑上。

  • 在Mac系统中这些文件会同步到“~/Library/Logs/CrashReporter/MobileDevice”下。

  • 在Windows系统中会同步到“C:UsersAppDataRoamingApple computerLogsCrashReporter/MobileDevice”（Vista或以上）或“C:Documents and SettingsApplication DataApple computerLogsCrashReporter”（XP）。

崩溃日志的发送

通过手机发送崩溃日志文本

打开系统设置中的“通用-关于本机-诊断与用量-诊断与用量数据”，你会看到一个按App包名排序的崩溃日志列表，找到相应App的崩溃日志并打开，复制崩溃日志内容发送给相应的开发者。开发者可以复制收到的日志文本保存为扩展名是crash的文本文件。

通过日志文件发送

当手机连接到iTunes时，会将崩溃日志文件同步到电脑上。在Mac系统中，可以到“~/Library/Logs/CrashReporter/MobileDevice”目录中找到该文件，而Windows系统在“C:UsersAppDataRoamingApple computerLogsCrashReporter/MobileDevice”（Vista或以上）或“C:Documents and SettingsApplication DataApple computerLogsCrashReporter”（XP）。可以将这些文件发送给开发者。

自动上传崩溃日志到iTC(iTunes Connect)

iOS中崩溃日志是可以上传的iTC的服务器，并由开发者查看的。用户可以通过系统设置中的“通用-关于本机-诊断与用量”来设定是否上传崩溃日志。同时开发者也可以通过捕获异常信号自己定制异常上报。

崩溃日志的格式

一般崩溃日志头部有如下字段

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x20000008
Crashed Thread:  0

其中Exception Type是异常类型，Exception Codes是异常代码。Crashed Thread指示异常的线程编号。上面表示Crash的线程编号是0（主线程的线程编号是0）。

看崩溃日志时一般要分两种情况，一种是内存、CPU的系统错误，如内存访问错误、除零异常等。另外一种是程序通过写代码抛出的异常，即代码中通过throw关键字抛出的异常。程序抛出的异常是可以捕获并处理的，如果没有捕获，就会Crash，并生成崩溃日志。这两种在日志中有一些细微的差别。

一般内存等系统异常Crash线程信息如下：

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x3624cf78 objc_msgSend + 16
1   QQYanChu                        0x0000d92a -[QYServerInterface connectionDidFinishLoading:] (QYServerInterface.m:328)
2   Foundation                      0x30d03c22 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 10
3   Foundation                      0x30c5b6d2 -[NSURLConnectionInternalConnection invokeForDelegate:] + 22
4   Foundation                      0x30c5b69c -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 192
5   Foundation                      0x30c5b5be -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 54
6   CFNetwork                       0x338077ee URLConnectionClient::_clientDidFinishLoading(URLConnectionClient::ClientConnectionEventQueue*) + 186
7   CFNetwork                       0x337fc49e URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 418
8   CFNetwork                       0x337fc592 URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 662
9   CFNetwork                       0x337fc19c URLConnectionClient::processEvents() + 100
10  CFNetwork                       0x337fc0d2 MultiplexerSource::perform() + 150
11  CoreFoundation                  0x34dffacc __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 8
12  CoreFoundation                  0x34dff298 __CFRunLoopDoSources0 + 208
13  CoreFoundation                  0x34dfe03e __CFRunLoopRun + 646
14  CoreFoundation                  0x34d8149e CFRunLoopRunSpecific + 294
15  CoreFoundation                  0x34d81366 CFRunLoopRunInMode + 98
16  GraphicsServices                0x3607d432 GSEventRunModal + 130
17  UIKit                           0x31e77e76 UIApplicationMain + 1074
18  QQYanChu                        0x0000feea main (main.m:39)
19  QQYanChu                        0x00007ed4 start + 32

第一列是编号，表示堆栈中函数调用的嵌套顺序。最上面就是崩溃发生的函数，往下面看就可以看到我们的代码。第二列是堆栈中函数定义的位置，有的是在动态库或Framework中定义的，有的是我们的App定义的，如QQYanChu就是我们的App可执行文件，另外你还可以看到其他的动态库等，一般我们关注自己的QQYanChu的就行了。 如上面的例子就是在-[QYServerInterface connectionDidFinishLoading:] 这个调用中挂的。一般这个信息还会包含代码文件和说对应的行号，如上面红色部分就是说崩溃在QYServerInterface.m的328行。这就可以方便我们快速定位问题。

下面是程序抛出的异常的日志。

Last Exception Backtrace:
0   CoreFoundation                  0x3425929e __exceptionPreprocess + 158
1   libobjc.A.dylib                 0x33a2b97a objc_exception_throw + 26
2   CoreFoundation                  0x3425ce02 -[NSObject(NSObject) doesNotRecognizeSelector:] + 166
3   CoreFoundation                  0x3425b52c ___forwarding___ + 388
4   CoreFoundation                  0x341b2f64 _CF_forwarding_prep_0 + 20
5   QQYanChu                        0x000ef372 -[QYUser staticDataFetcher:fetchedData:] (QYUser.m:168)
6   QQYanChu                        0x001ee9f2 -[QStaticDataFetcher successWithData:] + 94
7   QQYanChu                        0x001efb44 -[QStaticDataFetcher sendDelegateMessageWithLocalData] + 220
8   Foundation                      0x39256a6a __NSFireDelayedPerform + 446
9   CoreFoundation                  0x3422e5da __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 10
10  CoreFoundation                  0x3422e28c __CFRunLoopDoTimer + 268
11  CoreFoundation                  0x3422cefc __CFRunLoopRun + 1228
12  CoreFoundation                  0x3419feb8 CFRunLoopRunSpecific + 352
13  CoreFoundation                  0x3419fd44 CFRunLoopRunInMode + 100
14  GraphicsServices                0x34f082e6 GSEventRunModal + 70
15  UIKit                           0x36de52fc UIApplicationMain + 1116
16  QQYanChu                        0x000fcfc0 main (main.m:39)
17  QQYanChu                        0x000ee4d4 start + 36


Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x32f28350 __pthread_kill + 8
1   libsystem_c.dylib               0x3830311e pthread_kill + 54
2   libsystem_c.dylib               0x3833f96e abort + 90
3   libc++abi.dylib                 0x38e35d4a abort_message + 70
4   libc++abi.dylib                 0x38e32ff4 default_terminate() + 20
5   libobjc.A.dylib                 0x33a2ba74 _objc_terminate() + 144
6   libc++abi.dylib                 0x38e33078 safe_handler_caller(void (*)()) + 76
7   libc++abi.dylib                 0x38e33110 std::terminate() + 16
8   libc++abi.dylib                 0x38e34594 __cxa_rethrow + 84
9   libobjc.A.dylib                 0x33a2b9cc objc_exception_rethrow + 8
10  CoreFoundation                  0x3419ff1c CFRunLoopRunSpecific + 452
11  CoreFoundation                  0x3419fd44 CFRunLoopRunInMode + 100
12  GraphicsServices                0x34f082e6 GSEventRunModal + 70
13  UIKit                           0x36de52fc UIApplicationMain + 1116
14  QQYanChu                        0x000fcfc0 main (main.m:39)
15  QQYanChu                        0x000ee4d4 start + 36

可以看出相比系统异常日志中多出了Last Exception Backtrace字段。上面是线程0崩溃的，而线程0只调用的abort。这是我们要看Last Exception Backtrace这里的堆栈，这个堆栈是抛出异常时的线程当时的堆栈情况，这个信息才是有意义的。在我们程序抛出异常后，系统会执行一系列相关逻辑后调用abort异常结束程序。

iOS崩溃日志分析，一键即可完成。-Swift开发
05-27
CrashAnalyse iOS崩溃日志分析，省了各种命令。 需要完成的功能（首先选择输入文件）1.首先检查文件是否存在，命令行文件（提供命令l CrashAnalyse iOS崩溃日志分析，省敲各种命令。需要完成的功能（首先选择输入文件）1.首先检查文件是否存在，命令行文件（默认情况下提供命令行文件），dsym文件（手动选择dsym文件并记录路径以方便下次自动选择），崩溃日志文件（手动选择日志文件并方便记录子自动选择），设置输出文件路径（手动选择输出路径并记录
iOS应用的crash日志的分析基础
热门推荐
JasonLee的专栏
02-10 5万+
Outline 如何获得crash日志 如何解析crash日志 如何分析crash日志      1. iOS策略相关      2. 常见错误标识      3. 代码bug 一、如何获得crash日志 当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志
IOS 崩溃日志分析
weixin_33712881的博客
08-08 230
1、手机连接电脑，打开Xcode的Devices列表，找到崩溃app的iphone。选中Device Logs，找到app的崩溃。 2、如果是上架应用，可以从iTunes Content获取到崩溃日志，选择Manage Your Applications，点击图标下面的View Details，点右边的Crash Reports。 让我们看看崩溃日志里面包含了什么： 进程信息 Incident...
iOS应用崩溃日志分析
唐大帅的编程之路
08-02 3130
作为一名应用开发者，你是否有过如下经历? 为确保你的应用正确无误，在将其提交到应用商店之前，你必定进行了大量的测试工作。它在你的设备上也运行得很好，但是，上了应用商店后，还是有用户抱怨会闪退 ! 如果你跟我一样是个完美主义者，你肯定想将应用做到尽善尽美。于是你打开代码准备修复闪退的问题……但是，从何处着手呢？ 这时iOS崩溃日志派上用场了。在大多数情况下，你能从中了解到关于闪退的详尽、有用的信息。 通过本教程，你将学习到一些常见的崩溃日志案例，以及如何从开发设备和iTunes Connect上获取崩溃日志文
iOS 崩溃日志分析工具
07-14
总的来说，iOS崩溃日志分析工具是开发者不可或缺的助手，它简化了崩溃日志的解读过程，使问题定位更加迅速，大大提高了开发团队的生产力。正确使用这些工具，可以显著提升iOS应用的质量和用户体验。
DSYM--iOS崩溃日志分析工具
11-04
三、崩溃日志分析 1. **获取崩溃日志**：崩溃日志可以通过用户的设备、TestFlight、Apple的Crash Reporter或第三方服务如Firebase Crashlytics获取。日志中包含了时间戳、设备信息以及关键的堆栈信息。 2. **匹配...
swift-iOS崩溃日志分析省的敲各种命令。
08-15
对于“swift-iOS崩溃日志分析”这个主题，我们可以采取以下步骤来解析和理解日志： 1. **获取崩溃日志**：这可以通过Xcode的设备和模拟器窗口，或者通过iTunes同步设备获取。此外，也可以从用户反馈或Crashlytics等...
iOS崩溃日志分析工具dSYM.zip
11-18
dSYM文件分析工具、用于崩溃日志分析、~/资源库/Developer/Xcode/Archives路径下 找到对应的dSYM文件，然后根据崩溃平台的日志信息、根据工具、输入后得出崩溃结果。系统10.15可用、版本1.0.3
iOS崩溃日志分析及搜集
yaphetsehome的博客
09-27 1169
当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志例外）。 1.日志获取 方式1 开发、测试阶段设备就在身边，可以连接设备，打开Xcode - Window - Devices - View Device Log 能够看到设备上的崩溃信息，但是如果缺少符号化崩溃日志的必要文件时
ios崩溃日志收集_iOS 崩溃日志分析（个人总结，最实用）
weixin_36269733的博客
12-29 2898
要分析奔溃日志需要三个文件：crash日志，symbolicatecrash分析工具，.dSYM符号集0. 在桌面创建一个crash文件夹1. 需要Xcode自带的崩溃分析工具symbolicatecrash，这个文件的位置参考：/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/...
iOS了解崩溃和崩溃日志（Understanding Crashes and Crash Logs）
gcs的博客
05-12 2299
当App发生crash时, attached的debugger会暂停App的运行，并定位的crash位置。详细看一下crash栈，这里是App启动入口这里是crash的具体位置发生crash时,debugger会收到signal，然后暂停App的运行,显示crash的调用栈如果当前没有attached的debugger，系统会吧crash堆栈信息dump到一个log文件中release版本的app发生crash时，log文件的调用栈只有地址信息xcode符号化后的crash log。
Swift-iOS崩溃日志分析：提高效率的自动化工具使用
weixin_42497762的博客
05-19 1055
崩溃日志是程序在遇到严重错误而终止时生成的记录文件，它详细描述了程序崩溃前发生的一系列事件，包括错误的类型、错误发生时程序的状态以及系统资源的使用情况。通过分析崩溃日志，开发者可以诊断出导致崩溃的具体原因，进而修复程序中的缺陷。
iOS应用崩溃日志分析工具：高效定位问题
weixin_42405592的博客
06-20 1095
在iOS应用开发中，应用崩溃是不可避免的现象，这些崩溃信息会以日志的形式存储，成为开发者分析和解决问题的重要资源。崩溃日志分析工具可以帮助我们理解崩溃的原因，快速定位问题所在，并提供解决问题的线索。掌握这些工具的使用是提高应用质量的关键步骤。iOS开发者通常依赖于Xcode自带的工具，如Instruments和Console，以及第三方工具如Crashlytics等。这些工具提供了从基础崩溃日志分析到高级的实时崩溃报告功能，能够帮助开发者从不同的角度和维度深入理解崩溃情况，快速响应和解决崩溃问题。
iOS第六十六篇：崩溃日志分析指南
I_did_it的博客
08-03 1150
【代码】iOS第六十六篇：崩溃日志分析指南。
iOS崩溃分析
IOS研究专栏
10-09 3537
方法一 首先查看crash log中的崩溃线程，假如是这样的：  Thread 0 Crashed:  0   libobjc.A.dylib                0x00003ec0 objc_msgSend + 24  1   MyApp               0x000036d2 0×1000 + 9938  我们得到了用户发生崩溃情况的内存地址：0x
命令行工具解析Crash文件,dSYM文件进行符号化
weixin_33813128的博客
03-17 344
备份   文／爱掏蜂窝的熊（简书作者）原文链接：http://www.jianshu.com/p/0b6f5148dab8著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。 序 在日常开发中，app难免会发生崩溃。简单的崩溃还好说，复杂的崩溃就需要我们通过解析Crash文件来分析了，解析Crash文件在iOS开发中是比较常见的。 获取崩溃信息方式 在iOS中获取崩溃信息的方...
IOS —— Crash分析
LinShunIos的博客
10-27 3382
常见crash类型 容器越界 使用未初始化的变量 用户授权问题 选择器方法未定义 子线程刷新ui KVO 数据类型不匹配 内存溢出 野指针 死循环
iOS-APP崩溃分析
MOON_YZM的博客
10-27 3072
程序崩溃是宣判app死亡的直接因素，仔细看工程崩溃日志，会有一些相应的信号输出给我们，根据崩溃类型我们可以快速的思考到与其类型相对应的崩溃场景，那么都有哪些崩溃类型呢？又有哪些崩溃信号呢？
threadsafe_queue.cpp: In member function ‘void threadsafe_queue<T>::wait_and_pop(T&)’: threadsafe_queue.cpp:29:44: error: ‘operator()’ declared as function returning a function 29 | _data_cond.wait(_mtx, [this]->bool(){ | ^ threadsafe_queue.cpp: In member function ‘std::shared_ptr<_Tp> threadsafe_queue<T>::wait_and_pop()’: threadsafe_queue.cpp:38:48: error: ‘operator()’ declared as function returning a function 38 | _data_cond.wait(_mtx, [this]->bool(void){ | ^
最新发布
10-22
<think>我们正在解决一个关于threadsafe_queue.cpp文件中成员函数wait_and_pop出现的错误：'operator()'被声明为返回函数的错误。 根据错误信息，这通常是由于函数声明或定义的语法问题导致的。例如，可能将函数声明为返回一个函数类型，而不是返回一个值。 在C++中，函数不能直接返回一个函数，但可以返回函数指针或函数对象（如lambda表达式）。因此，错误可能是由于在声明返回类型时使用了不正确的语法。 参考引用[1]中提到的，wait_and_pop函数通常与条件变量一起使用，使用std::unique_lock来等待条件满足。 典型的wait_and_pop函数有两种形式： 1. 第一种：传入一个引用参数来存储弹出的值，并返回void。 2. 第二种：返回一个值（通过构造一个shared_ptr或者直接返回值）。但要注意，返回值的版本可能会在拷贝/移动时抛出异常，因此需要谨慎。 我们来看一下可能出错的代码模式： 错误示例1：试图将函数作为返回类型 auto wait_and_pop() -> void(); // 错误：这里声明返回一个函数类型，该函数返回void，而不是返回void 错误示例2：在函数声明中误用了括号 void wait_and_pop(T& value)() { ... } // 错误：多了一对括号，导致声明了一个函数返回函数类型 正确声明应该是： void wait_and_pop(T& value); 或者 T wait_and_pop(); 另外，如果采用返回智能指针的方式： std::shared_ptr<T> wait_and_pop(); 因此，我们需要检查threadsafe_queue.hpp（或.cpp）中wait_and_pop的声明和定义，确保语法正确。 根据引用[1]中的描述，wait_and_pop的实现通常如下： 版本1（传入引用）： void wait_and_pop(T& value) { std::unique_lock<std::mutex> lk(mut); data_cond.wait(lk, [this]{return !data_queue.empty();}); value = data_queue.front(); data_queue.pop(); } 版本2（返回shared_ptr）： std::shared_ptr<T> wait_and_pop() { std::unique_lock<std::mutex> lk(mut); data_cond.wait(lk, [this]{return !data_queue.empty();}); std::shared_ptr<T> res(std::make_shared<T>(data_queue.front())); data_queue.pop(); return res; } 所以，错误可能是由于在声明或定义函数时，不经意间在函数名后面多了一个括号，导致编译器认为我们在声明一个返回函数的函数。 请检查你的代码中wait_and_pop的声明和定义。例如： 错误的声明： void wait_and_pop(T& value)(); // 多了一对括号 正确的声明： void wait_and_pop(T& value); // 没有多余的括号 或者，如果你使用的是返回shared_ptr的版本： std::shared_ptr<T> wait_and_pop(); // 注意：这里没有多余的括号 另外，也要检查成员函数定义的语法。定义时，函数名后面只有参数列表，不应该再有额外的括号。 例如，定义应该是： void threadsafe_queue<T>::wait_and_pop(T& value) { // ... } 而不是： void threadsafe_queue<T>::wait_and_pop(T& value)() { // 错误：多了一对括号 // ... } 因此，请仔细检查函数声明和定义处的语法，确保没有多余的括号。 如果问题仍然存在，请提供出错的代码片段，以便更准确地定位问题。 注意：根据引用[2]，你可能还面临一些环境兼容性问题，但当前错误是编译错误，与环境兼容性问题不同。 总结：检查wait_and_pop函数的声明和定义，确保没有多余的括号，并且返回类型正确。 </think>### 解决 `threadsafe_queue.cpp` 中 `wait_and_pop` 成员函数的错误 错误 `'operator()' 被声明为返回函数` 通常是由于 **Lambda表达式语法错误** 或 **函数声明歧义** 导致的。以下是具体解决方案： --- ### 错误原因分析 1. **Lambda表达式错误** `std::condition_variable::wait` 的谓词参数（第二个参数）必须是**可调用对象**，但可能被错误声明为返回函数类型： ```cpp // ❌ 错误示例：Lambda 的返回类型声明错误 data_cond.wait(lk, [](){ return !data_queue.empty(); }); // 若写成 []()() { ... } 会导致返回函数类型 ``` 2. **成员函数声明歧义** 函数声明时误用 `operator()` 语法： ```cpp // ❌ 错误示例：声明了一个返回函数的函数 void wait_and_pop()(); // 多出的一对括号导致歧义 ``` --- ### 修复步骤（两种常见实现） #### 方案一：传入引用参数（推荐） ```cpp void wait_and_pop(T& value) { // ✅ 正确声明 std::unique_lock<std::mutex> lk(mut); // ✅ 正确的Lambda表达式：返回布尔值 data_cond.wait(lk, [this] { return !data_queue.empty(); }); value = data_queue.front(); data_queue.pop(); } ``` **关键点修正**： 1. 移除Lambda中多余的 `()` 错误形式 `[this]() { ... }` 可能被误写为 `[this]()() { ... }` 2. 确保函数声明无多余括号 正确形式为 `wait_and_pop(T& value)`，而非 `wait_and_pop(T& value)()` #### 方案二：返回智能指针 ```cpp std::shared_ptr<T> wait_and_pop() { // ✅ 正确声明 std::unique_lock<std::mutex> lk(mut); data_cond.wait(lk, [this] { return !data_queue.empty(); }); // ✅ Lambda auto res = std::make_shared<T>(data_queue.front()); data_queue.pop(); return res; } ``` --- ### 错误排查清单 1. **检查Lambda表达式格式** - 确保为 `[capture] { ... }` 或 `[capture]() { ... }` - 禁止出现嵌套括号如 `[capture]()() { ... }` 2. **校验成员函数声明** - 函数签名后禁止追加 `()`： 正确：`void wait_and_pop(T&)` 错误：`void wait_and_pop(T&)()` 3. **验证头文件依赖** - 包含必要头文件： ```cpp #include <mutex> #include <condition_variable> #include <queue> ``` --- ### 底层机制解析 `std::condition_variable::wait` 的工作流程[^1]： 1. 检查谓词条件（如 `!data_queue.empty()`） 2. 若条件不满足，**释放锁**并挂起线程 3. 被唤醒后**重新获取锁**，再次检测条件 4. 条件满足则继续执行 此过程需配合 `std::unique_lock`（而非 `std::lock_guard`），因其支持灵活的锁管理[^1]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值