如果是c的话就是　４　１　１
看用的是什么编译器了

MinGW编译，结果 4 1 1

直接调取的'a'是从默认的地方调取的，那么默认的地方在哪？当然是，你程序运行在哪，这个默认就从哪来。

恭喜你发现了一个来自系统底层的小彩蛋，可惜，没有奖励

至于为什么是4字节，我想这可以用字节对齐的说法来解释，映像中在远古级追求高效率高速率的应用开发中有特别强调字节对齐这一概念，似乎是字节对齐的情况对于提高高负载寻址的速率有正面影响，因为在32位系统中，内存寻址方式是32bit即4x8bit（CPU寄存器起决定性效果），我想此处汇编dalao已经擦好手掌准备找错打脸了，就不多废话了，简单来说，这就是个“为了更高速率牺牲一定的存储空间”的细节表现了

理论上来说，'a'是一个字节大小，实际上来说，'a'是97，97这个数值，可以存储在char,int,long,long long等等整形数值的空间中，所以直接sizeof('a')得到的结果是什么都不用奇怪，这取决于系统的设定(因为'a'是预设好的常量，而程序内的c是自行声明的char类型变量)

赞一下

to 楼主：除此之外，sizeof表达式值评估类型为 size_t，不是 int。
在printf中，int对应%d，而size_t对应%zu。（VC宣称从VC2013开始计划逐步支持C语言，所以VC2013之前的版本就不要试了）

#include <stdio.h>

int main( void )
{
    printf("%zu %zu\n", sizeof 'a' , sizeof(char) );
}

张冠李戴
没有什么从默认地方调取
sizeof 'a' 就是一个编译期常量
编译器直接把这个表达式替换成 int类型的字节数

和字节对齐没有什么关系
只是因为 'a'是一个int而已
顺便 'a' 是常量 根本不占用内存 更谈不上什么对齐

"所以直接sizeof('a')得到的结果是什么都不用奇怪"
得到 sizeof(int) 以外的结果都值得奇怪 你对常量的了解太少了

你可以试一下sizeof(6.6)，你看一下是４还是８，是float呢还是double类型的。

也许是我学识浅薄理解过于片面了

我的理解是，程序是在系统上编译的，很大一部分东西都会直接利用系统交互来完成，像常量这些东西我的想法是它们虽然是编译的时候就存在的，但不可能无中生有，要么是存储在编译器的程序初始化环境，要么就是直接从系统获取相关讯息，而为什么要用四个字节的int类型来保存一个字节就能保存的char类型的ASCII字符'a'呢，无关内存看起来没错，但只是它早就占用内存了，而不是本身不存在到用时就一用即来对吧，毕竟我们并没有对'a'进行声明，确切来说，所有字符集我们都没进行声明，它们是在编译器&&系统之中已经保存有相关数据了。

这里我个人就有两个假设的可能性

第一，不论它来自于系统，还是编译器程序，它都是int类型的空间保存的，原因是为了向后兼容，可以添加各种语言的文字，统一保存为int类型，为什么要统一？直接继续用char保存不好么，97而已，自然是为了对齐统一省事吧？连结构内成员编译器都会自行对齐，这个我觉得有存在意义。

第二，依旧不论它来自于系统，还是编译器，在windows的环境下编译，它从32位系统诞生时就被定义为4个字节的int类型保存了，这个干脆就是为了字节统一（就个人所知，纯64位的CPU，仅曾经在intel的服务器CPU上出现过几例，后面的64位仅仅是32兼容64(x64)，这些东西肯定有关联），而在32位模式中，4字节的数据是一步到位的，以至于系统底层就考虑这种对齐的做法，所以它们的这些表现有关联这种猜想没问题吧？

基于这些推测，那么我就认为，sizeof('a')不论是什么结果，都取决于系统或编译器的设定，而不是个人主观臆测，对结果不必太过惊讶，坦然接受，也可以深入挖掘原理，这种想法我认为没有太大问题，当然有详细且正确的资料，欢迎指正，我也只是条咸鱼罢了。

当然，以上纯粹猜测，还是我懂得太少，也许什么时候我是那种能手动撸个系统出来的dalao，我才有资格下定论吧。

假设 int 4个字节
sizeof('a')编译之后 直接是 4
和直接写4 完全一样

'a'是char型我都知道

你知道的是错的