Linux的ls -l命令输出的第二列的数字代表什么?
简单来说，`ls l` 命令输出的第二列数字，代表的是文件的链接数。
下面，我们来深入剖析一下这个“链接数”究竟是怎么回事，以及它背后的逻辑。
什么是链接？
在 Linux 文件系统中，“链接”就像是文件的一个别名或者一个指针。你可以把一个文件想象成一个房间，而链接就是指向这个房间的门牌号。一个文件可以有多个门牌号指向它，无论你通过哪个门牌号进入房间，你看到的都是同一个房间里的东西。
链接主要有两种类型：
1. 硬链接 (Hard Link)：
硬链接是同一个文件的多个名字。
它们直接指向文件的数据块（inode），而不是通过文件名。
这意味着，如果你创建一个文件的硬链接，那么这个链接和原始文件是完全平等的，共享相同的数据和元数据（比如修改时间、权限等）。
删除一个硬链接，并不会影响文件的内容，也不会影响其他指向该文件的硬链接。只有当指向该文件的所有硬链接都被删除时，文件的数据块才会被真正释放。
重要限制： 硬链接不能跨文件系统（分区），也不能链接到目录（为了避免循环引用导致文件系统混乱）。
2. 符号链接 (Symbolic Link) / 软链接 (Soft Link)：
符号链接更像是 Windows 中的快捷方式，或者一个指向另一个文件路径的特殊文件。
它本身是一个独立的文件，其内容是另一个文件或目录的路径。
当你访问符号链接时，系统会跟随这个链接，去访问它指向的那个文件或目录。
符号链接可以跨文件系统，也可以链接到目录。
删除符号链接，只会删除这个“快捷方式”，而不会影响被链接的文件或目录。
如果它指向的文件或目录被删除了，那么这个符号链接就会变成一个“断开的链接”（dangling link），指向一个不存在的目标。
链接数的工作原理
在 Linux 文件系统中，文件的元数据（metadata）是存储在 inode (索引节点) 中的。每个文件或目录都有一个唯一的 inode。inode 包含了文件的所有重要信息，例如：
文件类型（普通文件、目录、符号链接等）
文件权限 (permissions)
所有者 (owner)
所属组 (group)
文件大小 (size)
最后访问时间 (atime)
最后修改时间 (mtime)
最后状态改变时间 (ctime)
指向数据块的指针 (pointers to data blocks)
链接计数 (link count)
这个链接计数，就是 `ls l` 输出第二列所展示的数字。
对于普通文件： 这个数字表示有多少个硬链接指向该文件的 inode。
对于目录： 这个数字表示有多少个目录项（包括子目录和父目录的“.” 和 “..”）指向该目录的 inode。
每个子目录都会有一个指向其父目录的“..”，这会增加父目录的链接数。
目录本身也有一个指向自己的“.”，这也会计入链接数。
因此，一个空目录的链接数至少是 2 ('.' 和 '..')。如果一个目录有 N 个子目录，那么它的链接数将是 2 ('.' + '..') + N。
对于符号链接： 符号链接本身是一个文件，它也有一个 inode。`ls l` 在显示符号链接时，第二列显示的通常是 `1`，因为符号链接自身只有一个“名字”（就是符号链接文件本身），它不参与硬链接计数。
为什么链接数很重要？
链接数是 Linux 文件系统管理中一个非常关键的概念，它直接关系到文件的生命周期：
1. 文件空间的回收： 当你删除一个文件时，系统并不会立即擦除文件的数据。它只会减少该文件 inode 的链接数。只有当链接数降到零时，文件系统才会认为这个 inode 和它所指向的数据块不再被任何文件名引用，然后才会将这些空间标记为可用，以便后续使用。
2. 文件系统的完整性： 链接数保证了即使你删除了一个文件名（例如通过 `rm` 命令），只要还有其他硬链接指向它，文件数据就不会丢失。
3. 理解目录结构： 目录的链接数可以帮助我们理解目录结构的构成，尤其是子目录对父目录的引用。
举例说明：
假设我们有一个名为 `myfile.txt` 的文件。
1. 初始状态：
```
rwrr 1 user user 123 Jan 1 10:00 myfile.txt
```
这里的 `1` 就是 `myfile.txt` 的链接数。它表示只有一个文件名（`myfile.txt`）指向这个文件的 inode。
2. 创建硬链接：
```bash
ln myfile.txt mylink.txt
```
现在，我们创建了一个 `mylink.txt` 作为 `myfile.txt` 的硬链接。
执行 `ls l` 后：
```
rwrr 2 user user 123 Jan 1 10:00 myfile.txt
rwrr 2 user user 123 Jan 1 10:00 mylink.txt
```
可以看到，`myfile.txt` 和 `mylink.txt` 的链接数都变成了 `2`。这意味着现在有两个文件名指向同一个文件的 inode。
3. 删除一个硬链接：
```bash
rm mylink.txt
```
执行 `ls l` 后：
```
rwrr 1 user user 123 Jan 1 10:00 myfile.txt
```
`mylink.txt` 被删除了，但 `myfile.txt` 的链接数又回到了 `1`。文件数据仍然存在，因为 `myfile.txt` 还在引用它。
4. 创建符号链接：
```bash
ln s myfile.txt symlink.txt
```
现在，我们创建了一个指向 `myfile.txt` 的符号链接。
执行 `ls l` 后：
```
rwrr 1 user user 123 Jan 1 10:00 myfile.txt
lrwxrwxrwx 1 user user 10 Jan 1 10:05 symlink.txt > myfile.txt
```
注意 `symlink.txt` 的权限位是 `l`（表示链接），而且输出会显示它指向 `myfile.txt`。`symlink.txt` 的链接数是 `1`，这是它作为符号链接文件本身的计数。`myfile.txt` 的链接数仍然是 `1`，因为符号链接不影响目标文件的硬链接数。
总结
所以，`ls l` 命令输出的第二列数字，是文件（或目录）链接数的直观体现。对于普通文件，它表示有多少个硬链接指向其 inode；对于目录，它反映了目录的引用数量。理解这个数字，对于深入掌握 Linux 文件系统的工作原理至关重要。它不仅揭示了文件是如何被引用的，更解释了文件数据的存在与否是如何被管理的。
网友意见
前言
不知道是不是因为我最近实在是看不到什么构成问题的提问，好多问题连描述都看不懂，所以难得推过来一个新问题，虽然题目我刚看到时有点疑惑，但是结合下面细节描述我承认我确实看懂他问的是什么了（忽然有一种莫名的感动，亦或是悲哀）。既然这是个明确的问题，且描述较清楚，而且赶上我现在正好在等一个运行结果所以有些时间，那么就让我们开始这个问题的回答之旅吧。
通过官方文档查阅
遇到这种问题我们首先想到的就是翻阅文档。但是我知道这种问题可能有很多论坛贴吧式的不名来源的表述，我不是说这些表述一定是错的，但是对于本身就不能辨别真伪的初学者来说，从权威文档中寻找解释的意义更大。除了能让你获得更准确更原始的信息表述以外，有时还能让你看到知识本来的样子以及它的演变。
第一个想到的是就是直接"man ls"，但是很遗憾，里面只提到ls -l使用了long-format的输出形式，但是并没有给出long-format的具体解释。
于是我想到ls命令并不是Linux首创的，它应该有更原始的资料，比如Unix时期的，BSD的，甚至有可能有Posix标准。顺着这个思路我通过 ls的wikipedia 找到了ls在BSD和Unix时代的文档：
这两个文档都有对Long-format的解释。比如FreeBSD的解释（开头一部分）是：
The Long Format If the -l option is given, the following information is displayed for each file: file mode, number of links, owner name, group name, MAC label, number of bytes in the file, abbreviated month, day-of-month file was last modified, hour file last modified, minute file last modified, and the pathname. Posix给出的(部分)解释是：
If the -l option is specified, the following information shall be written for files other than character special and block special files: "%s %u %s %s %u %s %s
", <file mode>, <number of links>, <owner name>, <group name>, <size>, <date and time>, <pathname> 这里面都清楚的说明了单独的ls的-l选项的格式（非固定描述），让我们结合Linux下ls -l的一个普通输出来看一下：
$ ls -l img -rw-rw-r--. 1 test test 1073741824 Nov 26 11:40 img <file mode> <number of links> <owner name> <group name> <size> <data and time> <pathname> 可以看到Linux下的这行输出和Posix的标准完全对应上了，当然FreeBSD的描述中还说有MAC label（强制访问控制标签）等内容，但是这个不是默认输出要求，我们就关注我们现在看到的。
所以题目问的第二个数字是什么，也就是文件mode之后的那个数字，解释上说是"number of links"，直译过来就是“链接数”，这个对于初次看到的人来说可能有些莫不着头脑。让我们继续往下看。
通过原代码分析
在GNU/Linux系统中，ls命令来源于一个叫coreutils的项目，通过项目名称我们就可以知道这个项目在系统中的位置有多么重要了，很多我们常用的核心工具都在这里，比如ls。
这是GNU的项目，我们尝试从GNU获取这个项目的最新代码(2022-03-25)
# git clone https://git.savannah.gnu.org/git/coreutils.git # cd coreutils # ls src/ls.c src/ls.c 现在我们就拿到了ls.c的原代码，下面没有别的，开始读代码吧！通过阅读和调试：
$ gdb src/ls (gdb) set args -l AUTHORS 3421 err = do_stat (full_name, &f->stat); (gdb) 0x0000000000407d7c in do_stat (st=<optimized out>, name=<optimized out>) at src/ls.c:1201 1201 return do_statx (AT_FDCWD, name, st, 0, calc_req_mask ()); (gdb) bt #0 0x0000000000407d7c in do_stat (st=<optimized out>, name=<optimized out>) at src/ls.c:1201 #1 gobble_file (name=0x7fffffffe168 "AUTHORS", type=type@entry=unknown, command_line_arg=command_line_arg@entry=true, dirname=dirname@entry=0x41aa11 "", inode=0) at src/ls.c:3421 #2 0x0000000000403b91 in main (argc=3, argv=0x7fffffffdd88) at src/ls.c:1764 我们发现ls通过do_statx这个函数获取文件的属性信息，而这个do_statx的代码是这样的：
static int do_statx (int fd, char const *name, struct stat *st, int flags, unsigned int mask) { struct statx stx; bool want_btime = mask & STATX_BTIME; int ret = statx (fd, name, flags | AT_NO_AUTOMOUNT, mask, &stx); if (ret >= 0) { statx_to_stat (&stx, st); /* Since we only need one timestamp type, store birth time in st_mtim. */ if (want_btime) { if (stx.stx_mask & STATX_BTIME) st->st_mtim = statx_timestamp_to_timespec (stx.stx_btime); else st->st_mtim.tv_sec = st->st_mtim.tv_nsec = -1; } } return ret; } 可以看到它使用了一个典型的系统调用来获取文件的属性，那就是statx。其实这里是因为我当前的系统支持statx系统调用，这个系统调用在老的系统上是不支持的，在不支持的时候ls会使用老的stat系统调用。
好了，不管是statx还是stat系统调用，我们去看一下它的文档吧：
int statx(int dirfd, const char *pathname, int flags, unsigned int mask, struct statx *statxbuf); DESCRIPTION This function returns information about a file, storing it in the buffer pointed to by statxbuf. The returned buffer is a structure of the following type: struct statx { __u32 stx_mask; /* Mask of bits indicating filled fields */ __u32 stx_blksize; /* Block size for filesystem I/O */ __u64 stx_attributes; /* Extra file attribute indicators */ __u32 stx_nlink; /* Number of hard links */ ... 上面我们说ls -l输出的第二个数字"number of links"就是对应的stx_nlink这个成员。（stat系统调用也有一个struct stat{}结构体，也有一个st_nlink的成员。我们针对statx的stx_nlink继续来展开，stat与此同理）。我们在使用statx系统调用的时候会初始化一个没有有效值的struct statx结构体，然后让statx系统调用通过内核获取文件的属性后把有效值填入这个结构体并返回给用户。
下面我们就到内核中去看一下statx系统调用，它被定义在fs/stat.c中：
SYSCALL_DEFINE5(statx, int, dfd, const char __user *, filename, unsigned, flags, unsigned int, mask, struct statx __user *, buffer) { return do_statx(dfd, filename, flags, mask, buffer); } 在当前的Linux v5.17-rc8中它通过do_statx()->vfs_statx()->vfs_getattr()->vfs_getattr_nosec()的顺序调用到文件所属文件系统的具体getattr方法： inode->i_op->getattr。不同的文件系统会有不同的实现，我们以XFS文件系统为例看一下实现：
STATIC int xfs_vn_getattr( struct user_namespace *mnt_userns, const struct path *path, struct kstat *stat, u32 request_mask, unsigned int query_flags) { struct inode *inode = d_inode(path->dentry); ... stat->size = XFS_ISIZE(ip); stat->dev = inode->i_sb->s_dev; stat->mode = inode->i_mode; stat->nlink = inode->i_nlink; ... ... 嗯……看来XFS直接使用的当前文件在内存中的inode结构的i_nlink，我们还是回到VFS层，看到inode的i_nlink在VFS层的定义是：
struct inode { ... union { const unsigned int i_nlink; unsigned int __i_nlink; }; ... } 在一个联合体里两个变量，一个用于只读(i_nlink)，一个用于写的情况(__i_nlink)。那么我们看一下XFS在什么情况会修改__i_nlink。我们发现XFS修改__i_nlink主要通过xfs_bumplink （自增）， xfs_droplink（自减）以及稍微原始一些的set_nlink（直接设置数值）函数（当然还有别的）。
我们首先发现目录和文件初始nlink数值是不一样的：
error = xfs_dialloc(&tp, dp->i_ino, mode, &ino); if (!error) error = xfs_init_new_inode(mnt_userns, tp, dp, ino, mode, is_dir ? 2 : 1, rdev, prid, init_xattrs, &ip); 如果创建的是一个目录，那么初始nlink值是2（"."和".."后面解释），如果创建的是一个全新的普通文件，那初始值是1。
除此之外有两处比较典型的导致nlink值增长的地方（也有别的地方），分别是xfs_create()和xfs_link()。 xfs_link()很好理解，它就是我们熟悉的link系统调用:
link() creates a new link (also known as a hard link) to an existing file. 通常理解为创建硬链接。所以当为一个已知文件创建一个硬链接的时候，这个文件所对应的inode的nlink要增加:
int xfs_link( xfs_inode_t *tdp, xfs_inode_t *sip, struct xfs_name *target_name) { ... xfs_bumplink(tp, sip); ... } 而另一个xfs_create()它对应的其实是inode operations中的create/mkdir//mknod方法，这些方法一看就知道是用来创建新“文件”的。所以xfs_create的作用是在一个已知目录下创建一个新的文件/目录等。
int xfs_create( struct user_namespace *mnt_userns, xfs_inode_t *dp, struct xfs_name *name, umode_t mode, dev_t rdev, bool init_xattrs, xfs_inode_t **ipp) { int is_dir = S_ISDIR(mode); ... ... if (is_dir) { error = xfs_dir_init(tp, ip, dp); if (error) goto out_trans_cancel; xfs_bumplink(tp, dp); } ... ... } 但是它比较特殊的是，只有当要创建的是个目录的时候，才会增加所在目录的nlink。举例来说就是如果执行"mkdir /mnt/test/dir1/dir2"成功，那么会增加dir1这个inode的nlink数值，但是如果执行"touch /mnt/test/dir1/file"则不会。
所以我们发现对于XFS来说，两种情况影响nlink的数值，一种是增加或减少文件的硬链接数量，另一种是增加或减少一级子目录的数量。换句通俗点的话说就是：文件的nlink表示文件在当前文件系统内的硬链接数目，目录的nlink表示目录的一级子目录有多少（Linux也不支持目录的硬链接，具体原因可以参考我另外一个回答：linux为什么不能硬链接目录？）。
但是这里需要注意一点，并没有标准定义nlink到底指什么，特别是对于目录的情况。所以不同的系统或者不同的文件系统会有各自的实现，我们上面只是以Linux下的XFS为例得出的结论。当然实际上Linux上大部分我们常见的文件系统都遵循这个行为，我只是说我们不能将其作为恒定不变的准则，如果一个文件系统是这样那就是这样，如果不是这样那就要另外分析。
通过实际操作验证
为了验证我们的推论，我们做一些简单的操作来看看。
首先是创建空目录和空文件和一个字符设备文件：
# ls # mkdir dir # touch file # mknod mynull c 1 3 # ls -l total 0 drwxr-xr-x. 2 root root 6 Mar 26 02:49 dir -rw-r--r--. 1 root root 0 Mar 26 02:49 file crw-r--r--. 1 root root 1, 3 Mar 26 02:50 mynull 可以看出目录的初始nlink确实是2，普通文件和字符设备文件的初始nlink是1。
然后我们给文件创建硬链接：
# ln mynull mynull2 # ln file file2 # ln file file3 # ls -l total 0 drwxr-xr-x. 2 root root 6 Mar 26 02:49 dir -rw-r--r--. 3 root root 0 Mar 26 02:49 file -rw-r--r--. 3 root root 0 Mar 26 02:49 file2 -rw-r--r--. 3 root root 0 Mar 26 02:49 file3 crw-r--r--. 2 root root 1, 3 Mar 26 02:50 mynull crw-r--r--. 2 root root 1, 3 Mar 26 02:50 mynull2 可以看到普通文件由于增加了两个硬链接，所以nlink变为3。设备文件由于增加了一个硬链接所以nlink变成了2。
下面我们给目录下创建一些子文件（不创建目录）：
# touch dir/file{1,2,3} # ls dir file1 file2 file3 # ls -l total 0 drwxr-xr-x. 2 root root 45 Mar 26 03:00 dir ... 可以看到目录的nlink并没有变化，还是初始的2。那么下面我创建几个子目录试试：
# mkdir dir/dir{1,2,3,4} # ls dir dir1 dir2 dir3 dir4 file1 file2 file3 # ls -l total 0 drwxr-xr-x. 6 root root 125 Mar 26 03:02 dir ... 创建了4个一级子目录后，dir的nlink也跟着加4，变成了6，结果符合我们上面的分析。
结语
所以我们给出一个象征性的结论：ls -l输出的第二个域是“number of links”（简称nlink）,它是ls命令通过stat()或statx()系统调用获取到的inode的nlink数值。在Linux的一些常见文件系统上，这个数值对于文件来说表示文件的硬链接数，对于目录来说表示目录的一级子目录的个数。但是需要特别提醒的是目前并没有标准定义nlink的具体含义，特别是对于类似目录这样的特殊情况，所以不要将此作为放之四海皆准的结论，我们要保持开放的态度，具体问题具体分析。
类似的话题
-
要说 Linux 的核心思想，那得从它诞生的时代背景聊起。那时候，操作系统还是一个比较封闭且昂贵的东西，主要是大型机和小型机的天下。普通人想要玩点啥，要么得花大价钱，要么只能玩一些非常简陋的系统。这时候，一个叫 Linus Torvalds 的芬兰大学生，出于对现有操作系统的“不满”和对学习计算机原............. -
在 Linux 和 Windows 这两大操作系统之间，关于文件管理机制谁更优秀的讨论一直不绝于耳。要给出一个绝对的答案并不容易，因为“优秀”的标准会因使用者的需求、习惯和技术背景而异。但是，我们可以从多个维度来剖析 Linux 和 Windows 的文件管理机制，以便更清晰地理解它们的差异和各自的.............
-
关于 Linux 内核为何要映射到所有物理内存这个问题，咱们得从几个关键点来掰扯清楚。这可不是什么凭空捏造的规定，而是有着非常扎实的底层逻辑和实际运行需求驱动的。首先，得明白一个最核心的概念：内核就是整个操作系统的“大脑”。它负责管理硬件资源，调度进程，处理各种系统调用，保证程序能够正常运行。如果内.............
-
Linux 的强大之处，绝非一两句话能说尽。它像一把瑞士军刀，能应对千变万化的挑战，从最底层的硬件操作，到最顶尖的云计算服务，几乎无处不在，无所不能。要说 Linux 的强大，得从几个维度来细品：1. 极致的灵活性和可定制性：这是 Linux 最核心的魅力所在。你拿到手的，不是一个成品，而是一堆“零.............
-
你提到的TCP连接数量最大不能超过65535个，这个数字其实有几种理解方式，而且对于服务器如何应对百万千万的并发，也并非仅仅是“TCP连接数”一个数字就能概括的。我们来掰开了揉碎了聊聊这其中的门道。首先，澄清一下“65535”的含义：当你听到“65535”这个数字在TCP连接中出现时，通常指的是：1.............
-
Linux 的系统 API 和 Win32 API 在缩写的使用上确实存在显著的差异。造成这种差异的原因是多方面的，涉及历史发展、设计哲学、目标用户以及技术演变等因素。下面我们将详细探讨这些原因以及它们带来的优劣。 Linux 系统 API 为何到处是缩写？Linux 系统 API，通常指的是 PO.............
-
好的，我们来详细地比较一下 Windows 的 PowerShell 和 Linux 的 Terminal。它们都是命令行界面（CLI），但从设计理念、功能、生态系统以及使用方式上都有着显著的区别。 核心概念的差异 Windows PowerShell: 对象导向的脚本语言 核心： PowerS.............
-
这个问题挺有意思的，也触及了很多我们常讨论的关于开源、社区以及国内技术生态的话题。咱们掰开了揉碎了聊聊，为什么你觉得当初Linux的情况和现在你碰到的情况不太一样。首先，得回到Linux诞生的那个年代，也就是上世纪九十年代初。那时候，计算机科学的研究和发展，尤其是在操作系统这个基础领域，全球范围内都.............
-
要配置一台 Linux 学习主机，我的建议是：够用就成，别贪大求全，先把基础打扎实最重要。 很多人一上来就想搞服务器级别的配置，其实对于学习来说，很多时候是过犹不及，反而会增加不必要的复杂度和成本。我帮你拆解一下，怎么选怎么配，让你心里有数。 一、 我为什么推荐自己组装？1. 成本控制： 这是最直接.............
-
内核页表与 Linux 伙伴系统之间，用“冲突”来形容可能有些过于绝对，但它们之间确实存在一种微妙的、需要精心管理的协调与权衡。更准确地说，它们是在不同的抽象层次上运作，并且对内存的需求和分配方式有着截然不同的考量，这种差异可能会在特定情况下导致需要仔细处理的复杂性。为了理解这一点，我们需要先分别剖.............
-
VxWorks 与 Linux C++ 开发的“隔阂”有多深？对于从通用操作系统（比如 Linux）转向实时操作系统（RTOS）的开发者来说，VxWorks 的 C++ 开发体验，用“陌生”来形容丝毫不为过。这其中的差别，绝不是简单的 API 变动，而是根植于两者设计哲学、应用场景，乃至底层技术栈上.............
-
Windows 文件搜索给人的感觉确实比 Linux 慢，这背后有很多原因，而且这些原因交织在一起，共同导致了这种体验上的差异。这里我来跟你好好掰扯掰扯，尽量说得透彻点，让你明白为啥是这样。1. 索引机制的差异：Linux 的“按需”与 Windows 的“无处不在”这是最核心的区别之一。 Li.............
-
.......
-
.......
-
.......
-
大学C语言课选择Visual Studio（VS）而不是Linux下的GCC作为主要教学和开发环境，背后有着多方面的原因，这些原因交织在一起，共同塑造了教学的选择。这并非说GCC不好，而是VS在特定的教学场景下，提供了更符合当前多数学生背景和学习路径的优势。首先，得从学生群体和基础入手。当下进入大学.............
-
2021年，为Linux寻觅一款心仪的笔记本，确实是个不错的主意。随着Linux生态的日渐成熟，越来越多厂商开始关注Linux用户，市面上涌现出不少兼容性好、体验佳的机型。当然，想要一台真正“适合”的Linux笔记本，还需要从几个关键维度去考量。核心考量点：硬件兼容性与驱动支持这是选择Linux笔记.............
-
Android 之所以没有直接运行我们熟悉的 Linux 程序，而是构建了一套自己的运行环境，这背后其实是一系列深思熟虑的设计选择，旨在为移动设备这个特殊场景量身打造一个既强大又高效的操作系统。你可以想象一下，Linux 系统最初是为服务器和桌面电脑设计的，它们拥有相对充裕的计算资源、内存和标准化的.............
-
你这个问题问得挺有意思，也挺普遍的。确实，很多人觉得安卓的图形界面用起来顺畅舒服，而一些Linux的图形界面就显得没那么“给力”了。这背后其实涉及到很多技术和历史原因，咱们一点点聊。安卓的图形界面：为移动而生，体验至上安卓的图形界面，也就是大家常说的Android UI，它是为移动设备量身打造的。从.............
-
这真是一个值得深思的问题，我们不妨从几个层面来聊聊为什么在开放性这一点上，桌面和移动操作系统给我们带来的感受截然不同，以至于口碑呈现出一种鲜明的反差。首先，我们需要理解“开放”本身在不同平台上的语境和表现形式。桌面端的Windows和Linux，大家普遍认为它们是开放的。Windows虽然是商业软件.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有