cf_438_C Qualification Rounds

本文探讨了在有限的题目池中选择合适题目集的问题,确保每支参赛队伍最多只了解所选题目集的一半。通过状态压缩和枚举的方法,判断是否能成功构建这样的题目集。

Snark and Philip are preparing the problemset for the upcoming pre-qualification round for semi-quarter-finals. They have a bank of nproblems, and they want to select any non-empty subset of it as a problemset.

k experienced teams are participating in the contest. Some of these teams already know some of the problems. To make the contest interesting for them, each of the teams should know at most half of the selected problems.

Determine if Snark and Philip can make an interesting problemset!

Input

The first line contains two integers nk (1 ≤ n ≤ 1051 ≤ k ≤ 4) — the number of problems and the number of experienced teams.

Each of the next n lines contains k integers, each equal to 0 or 1. The j-th number in the i-th line is 1 if j-th team knows i-th problem and 0otherwise.

Output

Print "YES" (quotes for clarity), if it is possible to make an interesting problemset, and "NO" otherwise.

You can print each character either upper- or lowercase ("YeS" and "yes" are valid when the answer is "YES").

Examples
input
5 3
1 0 1
1 1 0
1 0 0
1 0 0
1 0 0
output
NO
input
3 2
1 0
1 1
0 1
output
YES
Note

In the first example you can't make any interesting problemset, because the first team knows all problems.

In the second example you can choose the first and the third problems.


题意:

给n个题目和k支队伍,每只队伍都可能已经知道一些题目,现在求是否能找出几个(也可以是一个)题目,使得每只队伍最多只了解这些题目中的一半。

输入的第i行第j列代表第j支队伍是否了解第i题,1是了解,0是不了解


思路:

刚开始瞎搞,结果卡在第10个测试点。。。

正解是状态压缩加枚举。。。orz

可以知道,如果能够找出,则必然最少有两题(一题的情况是都为0,和两题的意思一样)满足

那么将每个题目的了解情况压缩成一个十进制数,然后依次去做按位与,如果等于0,就能找出,否则不能。

由于k<=4,所以压缩后的值顶多为15,即有16种状态,这样就可以暴力枚举了


#include <iostream>
#include <cstdio>
#include <cstring>
#include <string>
#include <cmath>
#include <queue>
#include <algorithm>
#include <vector>
#include <stack>
#define INF 0x3f3f3f3f
#pragma comment(linker, "/STACK:102400000,102400000")
using namespace std;
int n, k;
bool a[1<<4+5];
int main()
{
    while(~scanf("%d%d", &n, &k))
    {
        memset(a, false, sizeof(a));
        for(int i=1; i<=n; i++)
        {
            int sum=0;
            for(int j=0; j<k; j++)
            {
                int x;
                scanf("%d", &x);
                sum+=(1<<j)*x;   //压缩
            }
            a[sum]=true;
        }
        bool flag=false;
        for(int i=0; i<16; i++)    //枚举
        {
            if(!a[i])
                continue;
            for(int j=0; j<16; j++)
            {
                if(!a[j])
                    continue;
                if((i&j)==0)
                {
                    flag=true;
                    break;
                }
            }
            if(flag)
                break;
        }
        if(flag)
            printf("YES\n");
        else
            printf("NO\n");
    }
    return 0;
}




<think>我们分析这个SQL语句:在MySQL5.7中,使用用户变量(如@row_number,@group)在查询中可能会因为优化器的行为而导致结果不稳定。而在MySQL8.0中,由于引入了窗口函数和更严格的用户变量求值顺序,结果更加稳定。具体到这个查询:SELECT*,@row_number:=IF(@group=spu,@row_number+1,1)ASrn,@group:=spuFROMstar_prod_real_image_qualification_newORDERBYspu,timedesc问题在于:在MySQL5.7中,优化器可能会改变SELECT列表中表达式的求值顺序。虽然我们写了先计算@row_number然后赋值@group,但是MySQL可能会先赋值@group再计算@row_number。这会导致在同一个spu分组内,第一行的@group已经被赋值为当前spu,然后计算@row_number时,IF条件判断@group(已经是当前spu)等于spu(当然相等),所以@row_number+1,而不是从1开始。这样第一行就会变成2,而第二行就会变成3,以此类推,导致第一行没有从1开始。而在MySQL8.0中,用户变量的这种行为被修改,并且官方不推荐在SELECT列表中使用用户变量来赋值,因为结果不可预测。但是在这个查询中,8.0的优化器可能保持了与5.7不同的行为,或者8.0中用户变量的求值顺序固定为书写顺序,所以结果稳定。解决办法(在5.7中):我们可以通过将用户变量的计算放在一个子查询中,并在外层查询中排序,以确保变量赋值和排序的顺序正确。另外,为了避免求值顺序问题,我们可以将两个用户变量的赋值分开,先计算row_number再赋值group,并且确保赋值group不会影响当前行的row_number计算。但是,更常见的做法是使用两个变量,并且在一个表达式中只使用一个变量并赋值另一个变量,避免相互干扰。然而,在这个例子中,我们计算rn时使用了@group,然后又更新了@group。一个常见的技巧是:将两个赋值操作放在同一个表达式中,通过将@group的赋值放在rn计算之后(即在同一个表达式中先使用@group,然后再更新它)。但是,由于MySQL对赋值顺序的不确定性,我们可以将赋值分开,并确保顺序。另一种方法:使用子查询,先排序,然后在外部查询中处理变量。我们可以这样改写:方法1(使用子查询,确保排序后再处理变量):SELECTt.*,@row_number:=IF(@group=t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC)tCROSSJOIN(SELECT@row_number:=0,@group:='')ASvarsORDERBYt.spu,t.timeDESC;但是,这种方法在5.7中可能仍然有问题,因为外层查询的ORDERBY可能被优化掉(因为内层已经排序),但MySQL有时会在外层重新排序。为了确保顺序,我们可以去掉外层ORDERBY,因为内层已经排序,但MySQL可能会保留这种顺序。然而,根据MySQL文档,不保证子查询的顺序传递到外层,所以外层需要再次排序。然而,再次排序可能会打乱内层的顺序,所以我们可以这样:SELECTt.*,@row_number:=IF(@group=t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC)tCROSSJOIN(SELECT@row_number:=0,@group:='')ASvarsORDERBYt.spu,t.timeDESC;--这里外层的排序可能会干扰变量的计算注意:外层的ORDERBY可能会导致变量计算在排序之前发生?实际上,在MySQL中,SELECT列表的表达式计算是在排序(ORDERBY)之前进行的(除了GROUPBY和聚合函数)。所以,我们这样写,变量计算是在排序之后吗?不是,整个查询的执行流程是:FROM->WHERE->SELECT->ORDERBY。所以,在SELECT中计算变量时,数据还没有排序(因为内层已经排序,但外层并没有再次排序,我们这里外层有ORDERBY,但变量计算是在ORDERBY之前)。所以,我们需要确保数据在变量计算前是有序的。因此,我们可以在子查询中排序,然后外层查询按顺序处理变量,并且不再需要外层排序(因为内层排序的结果会作为派生表,然后我们按顺序处理变量,最后的结果就是按内层排序的顺序)。但是,MySQL不保证派生表保持顺序,所以我们需要在外层也进行排序以确保。但是,如果我们在外层也进行同样的排序,那么数据顺序就是正确的,但是变量计算是在排序之前完成的,所以顺序可能会乱。因此,我们可能需要在变量计算后不再排序。实际上,我们可以在子查询中排序,然后外层直接使用这个顺序,不进行ORDERBY。但是,MySQL不保证SELECT派生表时顺序不变。所以,我们可以尝试不写外层的ORDERBY,但这样顺序可能被破坏。方法2:将变量赋值分开,先计算rn,然后再更新group,但是在一个SELECT中,MySQL可能以任意顺序执行。我们可以尝试将两个变量赋值分开为两个步骤,但是不能保证。方法3(推荐):将两个变量赋值放在同一个表达式,但确保先使用旧值再更新。在5.7中,我们可以调整顺序,先使用@group,然后再更新它。但是,在同一个SELECT项中,我们这样写已经是先使用再更新了。然而,问题在于,下一个SELECT项中更新了@group,可能会影响同一行中后续的表达式?但是这里只有两个表达式,第一个表达式使用@group(上一行的值)和更新@row_number,第二个表达式更新@group。所以,在计算第二个表达式时,第一个表达式已经计算完了。所以,同一行内,第一个表达式先执行,第二个表达式后执行。这样,我们在一行内先使用@group(上一行的值)计算rn,然后再将当前行的spu赋值给@group。这样应该是安全的。但是,为什么在5.7中不稳定?可能是因为优化器将两个表达式的顺序颠倒了?也就是说,它先执行了`@group:=spu`,然后再执行`@row_number:=...`。为了避免这种情况,我们可以将两个表达式合并成一个,确保先计算rn再更新group。我们可以这样写:SELECT*,@row_number:=IF(@group=spu,@row_number+1,1)ASrn,@group:=spu...但是,我们无法控制同一个SELECT子句中表达式的顺序。在MySQL中,同一个SELECT子句中的表达式是从左到右执行的。所以,我们必须确保先写计算rn的表达式,然后再写更新@group的表达式。然而,在5.7中,优化器可能会改变顺序,因为它认为这两个表达式没有依赖关系(实际上有:第二个表达式更新了@group,而第一个表达式依赖于@group的旧值)。所以,优化器可能会认为先更新@group再计算rn也可以,因为rn表达式没有使用@group?不对,rn表达式使用了@group。所以,理论上优化器不会改变这两个表达式的顺序。但是,由于用户变量的副作用,MySQL的优化器可能并不总是按从左到右的顺序执行。因此,在5.7中,官方文档已经警告了这种用法,并且结果可能不可预测。可靠的方法:升级到MySQL8.0,使用窗口函数。如果必须在5.7中运行,我们可以尝试将两个变量赋值放在一个表达式中,避免被分开。例如:SELECT*,@row_number:=IF(@group=spu,@row_number+1,IF(@group:=spu,1,1))ASrn...这样,我们将两个赋值放在一个表达式中。但是,这样写可读性差,而且IF函数的三元表达式,我们可以在条件判断中赋值@group,但是这样并不直观。具体改写:SELECT*,@row_number:=IF(@group=spu,@row_number+1,IF((@group:=spu)ISNOTNULL,1,1)--这里利用赋值表达式,同时判断是否为NULL(实际上我们不需要判断,只是为了语法))ASrnFROMstar_prod_real_image_qualification_newCROSSJOIN(SELECT@row_number:=0,@group:='')ASvarsORDERBYspu,timedesc;这里,我们将@group的赋值放在IF的condition部分(condition部分会先执行),这样在同一个表达式中,先执行了@group:=spu,然后再执行IF的判断?不对,这样顺序更乱了。所以,我们不推荐这种方法。更可靠的方法:使用两个子查询,分别计算。但是这样写复杂。或者,我们可以使用一个技巧:在SELECT列表中将两个表达式合并,但使用CASEWHEN确保顺序。不过,我们也可以尝试在同一个表达式中先使用@group,然后再更新@group,但这样就需要在一个表达式中完成两件事。实际上,我们可以这样:SELECT*,@row_number:=CASEWHEN@group=spuTHEN@row_number+1ELSE1ENDASrn,@group:=spu...但是,这跟原来的没有本质区别。经过思考,最稳妥的方法是在子查询中排序,然后在外层按顺序处理变量,并且不在外层进行任何可能破坏顺序的操作。同时,我们确保变量初始化的交叉连接(CROSSJOIN)放在外部,并且使用一个子查询来保证顺序。例如:SELECTt.*,@row_number:=IF(@group=spu,@row_number+1,1)ASrn,@group:=spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC)tCROSSJOIN(SELECT@row_number:=0,@group:='')varsORDERBYt.spu,t.timeDESC;--这里外层的ORDERBY可能会在变量计算之后重新排序,从而打乱顺序为了避免外层排序影响,我们去掉外层的ORDERBY,因为内层已经排序。但是,MySQL不保证派生表的顺序。所以,我们需要让MySQL知道我们要求顺序。我们可以尝试在外部查询中不进行排序,而是依赖内层排序。然而,根据MySQL文档,如果外部查询没有ORDERBY,那么结果的顺序是不确定的。所以,我们必须在外部查询加上ORDERBY。这样就形成了一个矛盾:变量计算需要顺序,而ORDERBY在变量计算之后执行,所以变量计算时顺序是内层顺序,但最终输出顺序又是外层ORDERBY的顺序。但是,变量计算后的结果(rn)是基于内层顺序的,而外层排序可能会改变行的顺序,导致rn与排序后的行不匹配。因此,我们必须在变量计算时保持正确的分组和顺序,而输出顺序也必须与变量计算时的顺序一致。所以,我们不需要外层排序,因为内层已经排好序。我们只需确保派生表t的顺序在外部查询中被保持。但是,MySQL不保证这一点。所以,我们只能寄希望于MySQL按派生表t的顺序输出(实际上,在没有GROUPBY和聚合函数的情况下,通常派生表会保持顺序)。我们可以尝试不写外层ORDERBY。SELECTt.*,@row_number:=IF(@group=t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC)tCROSSJOIN(SELECT@row_number:=0,@group:='')ASvars;这样,在5.7中,派生表t的顺序可能会被保留,所以变量计算按t的顺序进行。但是,根据MySQL文档,这仍然是不保证的。方法4:使用中间变量。在同一个SELECT表达式中,先使用@group,然后更新@group,但是将更新@group放在rn计算之后,并且确保MySQL从左到右执行。我们可以将两个表达式写在同一行,但这样不行。方法5:使用两个步骤,先更新row_number,再更新group,但是放在两个不同的SELECT项中,并且确保顺序。这依赖于MySQL从左到右执行SELECT项。而MySQL官方文档说,SELECT项的执行顺序是不确定的。所以,我们无法保证。因此,最可靠的方法还是升级到MySQL8.0,使用ROW_NUMBER()窗口函数。如果无法升级,那么我们可以尝试使用上述子查询方法,并祈祷顺序被保留。或者,我们可以使用临时表来存储排序后的结果,然后在临时表上更新变量。方法6(使用临时表):CREATETEMPORARYTABLEtemp_star_prodASSELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC;SET@row_number=0;SET@group='';SELECT*,@row_number:=IF(@group=spu,@row_number+1,1)ASrn,@group:=spuFROMtemp_star_prod;这样,临时表的数据是排序好的,然后我们按顺序读取临时表,变量赋值就会按排序好的顺序进行。但是,这种方法需要创建临时表,并且需要两个语句(或者在一个语句中完成,但需要先创建临时表,然后查询)。我们也可以在一个查询中完成,但需要两次扫描表(子查询一次,然后变量计算一次)。考虑到性能和复杂性,如果数据量不大,这种方法可行。方法7:使用内联子查询,但使用用户变量,并确保顺序。我们参考一些资料,发现一种常见的模式是:SELECTt.*,@row_number:=IF(@group=spu,@row_number+1,1)ASrn,@group:=spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC)t,(SELECT@row_number:=0,@group:='')varsORDERBYt.spu,t.timeDESC;--这里外层的ORDERBY可能会改变顺序,但变量计算已经完成,所以rn不会变,但行的顺序会变。注意:变量计算在ORDERBY之前,所以即使外层有ORDERBY,也不会影响变量计算的结果,但是会影响行的显示顺序。而变量计算时,数据顺序是子查询t的顺序(已经排序)。所以,这个查询的结果是:变量计算基于子查询t的顺序,然后外层再按同样的条件排序(实际上t已经是这个顺序,所以外排序不会改变顺序,因此结果正确)。为什么外层排序不会改变顺序?因为子查询t已经按spu,timeDESC排序,而外层排序条件相同,所以MySQL优化器可能不会重新排序(因为已经是排好序的)。所以,最终结果顺序正确,变量计算也正确。因此,我们可以这样写:SELECTt.*,@row_number:=IF(@group=t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYt.spu,t.timeDESC)tCROSSJOIN(SELECT@row_number:=0,@group:='')ASvarsORDERBYt.spu,t.timeDESC;在MySQL5.7中,这种写法可能会解决不稳定的问题,因为它确保了子查询中的顺序,然后变量计算在子查询的顺序基础上进行,最后外层排序与子查询相同,所以不会打乱顺序。但是,需要注意的是,子查询中的ORDERBY在派生表(t)中可能会被优化器忽略(如果外部查询有ORDERBY,优化器可能会合并排序)。因此,为了保险,我们可以使用优化器提示:SELECTt.*,@row_number:=IF(@group=t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC/*+NO_MERGE(t)*/--但是MySQL5.7可能不支持在子查询中使用提示来避免合并,具体语法需要测试)tCROSSJOIN(SELECT@row_number:=0,@group:='')ASvarsORDERBYt.spu,t.timeDESC;或者,我们可以使用一个LIMIT子句来强制子查询排序(如果表很大,不推荐),例如在子查询的ORDERBY后面加上LIMIT18446744073709551615(一个很大的数),这样MySQL会保持子查询的顺序。所以,改写为:SELECTt.*,@row_number:=IF(@group=t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESCLIMIT18446744073709551615)tCROSSJOIN(SELECT@row_number:=0,@group:='')ASvarsORDERBYt.spu,t.timeDESC;这样,子查询的排序不会被优化器忽略,然后外层查询的变量计算就可以按这个顺序进行。总结:在MySQL5.7中,我们可以使用上述LIMIT的方法来确保子查询的顺序,然后进行变量赋值,最后外层再排序(虽然顺序已经正确,但为了确保,我们保留ORDERBY)。因此,最终的解决方案是:SELECTt.*,@row_number:=IF(@group=t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESCLIMIT18446744073709551615)tCROSSJOIN(SELECT@row_number:=0,@group:='')ASvarsORDERBYt.spu,t.timeDESC;这样,在MySQL5.7中,结果应该稳定。但是,如果spu字段有NULL值,那么IF(@group=t.spu)可能会出问题(因为NULL不等于任何值,包括NULL),所以我们需要处理NULL的情况。可以将条件改为:@row_number:=IF(@group<=>t.spu,@row_number+1,1)使用<=>(NULL-safeequal)比较。所以,最终代码:SELECTt.*,@row_number:=IF(@group<=>t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESCLIMIT18446744073709551615)tCROSSJOIN(SELECT@row_number:=0,@group:=NULL)ASvarsORDERBYt.spu,t.timeDESC;注意:初始化@group为NULL,并且使用<=>比较。这样,即使spu为NULL,也能正确分组。解释:-子查询使用ORDERBYspu,timeDESC,并使用LIMIT18446744073709551615(一个很大的数,确保所有行被返回)来强制优化器保留排序。-然后,在外部查询中,我们初始化两个用户变量。-在外部查询的SELECT列表中,我们首先计算rn:如果当前行的spu和上一行(保存在@group中)相同,则行号+1,否则重置为1。这里使用<=>比较,可以处理NULL值。-然后,我们将当前行的spu赋值给@group,以便下一行使用。-最后,为了确保输出顺序和子查询一致,我们再次按spu,timeDESC排序(实际上子查询已经有序,所以这个排序很快,甚至优化器会忽略)。这种方法在MySQL5.7中应该能稳定工作。如果不想使用LIMIT,也可以尝试使用优化器提示,例如:SELECTt.*,@row_number:=IF(@group<=>t.spu,@row_number+1,1)ASrn,@group:=t.spuFROM(SELECT/*+NO_MERGE()*/--这个提示可能不起作用,具体需要测试*FROMstar_prod_real_image_qualification_newORDERBYspu,timeDESC)tCROSSJOIN(SELECT@row_number:=0,@group:=NULL)ASvarsORDERBYt.spu,t.timeDESC;但是,NO_MERGE提示在MySQL5.7中可能不适用于派生表。所以,使用LIMIT更可靠。因此,我们推荐使用LIMIT的方法。如果数据量非常大,这个LIMIT可能会影响性能,因为MySQL会先排序所有数据。但是,原查询也是要排序的,所以性能影响相同。所以,在5.7中的解决办法就是使用上述查询。</think>### 原因分析 在 MySQL 5.7 中,该查询结果不稳定的根本原因是 **用户变量(`@row_number`, `@group`)的求值顺序不确定**。具体来说: 1. **优化器行为**:MySQL 5.7 的优化器可能改变 `SELECT` 列表中表达式的执行顺序(即使书写顺序是先 `rn` 后 `@group := spu`)。 2. **变量依赖问题**: - 计算 `rn` 时需要依赖 `@group`(上一行的分组值) - 但 `@group := spu` 的赋值可能先于 `rn` 计算,导致当前行 `@group` 被提前更新 3. **数据扫描顺序**:未强制排序时,优化器可能选择不同的索引或全表扫描路径,导致处理行的顺序不同。 在 MySQL 8.0 中稳定的原因是: - 优化器对用户变量的处理更严格(但官方仍不推荐此用法) - 推荐改用标准的窗口函数(如 `ROW_NUMBER()`),其行为确定且可预测。 --- ### MySQL 5.7 的解决方案 通过 **子查询强制排序 + 变量初始化** 确保执行顺序。修改后的查询: ```sql SELECT t.*, @row_number := IF(@group <=> t.spu, @row_number + 1, 1) AS rn, -- 使用 <=> 处理 NULL @group := t.spu -- 在 rn 计算后更新分组 FROM ( SELECT * FROM star_prod_real_image_qualification_new ORDER BY spu, time DESC -- 先内部排序确保数据顺序 LIMIT 18446744073709551615 -- 强制优化器保留排序 ) t CROSS JOIN (SELECT @row_number := 0, @group := NULL) vars -- 初始化变量 ORDER BY t.spu, t.time DESC; -- 外层保持相同排序 ``` #### 关键改进解释: 1. **子查询强制排序**: - 内层 `ORDER BY spu, time DESC` 确保数据按分组和时间降序处理。 - `LIMIT 18446744073709551615`(MySQL 最大限制)强制优化器保留排序结果。 2. **安全的变量初始化**: - `CROSS JOIN` 初始化 `@row_number` 和 `@group`,避免会话残留值影响。 3. **NULL 安全比较**: - 使用 `<=>` 替代 `=` 比较 `@group` 和 `spu`,正确处理 `NULL` 值分组。 4. **执行顺序保障**: - 内层排序数据 → 变量初始化 → 按序处理每一行(先计算 `rn` 再更新 `@group`)。 --- ### 输出结果示例 假设原始数据: | spu | time | other_columns | |-----|------|---------------| | A | 10 | ... | | A | 8 | ... | | B | 12 | ... | **稳定输出**: | spu | time | ... | rn | @group | |-----|------|-----|----|--------| | A | 10 | ... | 1 | A | | A | 8 | ... | 2 | A | | B | 12 | ... | 1 | B | --- ### 终极建议:升级到 MySQL 8.0+ 使用标准窗口函数 **(推荐解决方案,无需 hack)**: ```sql SELECT *, ROW_NUMBER() OVER (PARTITION BY spu ORDER BY time DESC) AS rn FROM star_prod_real_image_qualification_new; ``` 优势: - 代码简洁易读 - 无变量副作用 - 性能优化更好 - 结果 100% 稳定 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值