According to many SO answers and this widely cited blog post, a .NET 4.5 application built for 'Any CPU' with the 'prefer 32-bit' option selected will run as a 32-bit process on both 32-bit and 64-bit systems (unlike in .NET 4.0 and earlier). In other words, x86 and AnyCPU with 'prefer 32-bit' selected are equivalent (ignoring whether or not it can run on ARM).
However, my tests have shown that on a 64-bit system an 'AnyCPU prefer 32-bit' application (which I confirm runs 32-bit) can allocate more memory than an x86 one. I wrote a .NET 4.5 C# console app that allocates 10MB byte arrays in a loop (keeping the references of course) until it hits an OutOfMemoryException, and ran it on a 64-bit system with plenty of RAM. When built as x86 it falls over at about 1.2GB allocated. The same code built as 'Any CPU (prefer 32-bit)' gets up to 1.5GB.
Why the difference?
It turns out that, in Visual Studio 2015, building as 'AnyCPU (prefer 32-bit)' sets the IMAGE_FILE_LARGE_ADDRESS_AWARE bit on the executable (equivalent to running editbin /LARGEADDRESSAWARE on it), whereas it does not for an x86 build. This can be confirmed with dumpbin /HEADERS and looking for the line "Application can handle large (>2GB) addresses".
This is not the case for Visual Studio 2013. The change is apparently undocumented.
In theory, this should give the CLR an additional 2GB to play with. I don't know why the allocatable memory only goes up by about 300MB.
来源：https://stackoverflow.com/questions/35068309/why-does-any-cpu-prefer-32-bit-allow-me-to-allocate-more-memory-than-x86-und