在我的情况下，有各种原因阻止我使用
JavaScriptSerializer。以下是其中的一些原因。
1）处理匿名类型时，反序列化效果不佳。
（删除线）
虽然对于序列化而言使用相当直截了当：
JavaScriptSerializer serializer = new JavaScriptSerializer();
String json = serializer.Serialize(data);
然而，对于反序列化来说，有一个小烦恼，即反序列化器会接受一个泛型类型以及内容：
serializer.Deserialize<T>(String s)
如果类型T在编译时未知且需要动态生成，则可能会出现问题。解决方法有点丑陋，因为它使用反射来创建通用方法（但它有效）。
var result = typeof(JavaScriptSerializer).GetMethod("Deserialize")
.MakeGenericMethod(JsonDataType)
.Invoke(serializer, new object[] { inputContent });
请注意：根据Dave Ward在这个答案中的评论，有一个DeserializeObject()可以用来预防此问题。
2）无法处理循环引用
我曾经遇到过这种情况，使用Entity Framework、Linq to SQL、NHibernate、NetTiers，甚至使用Castle's proxy时也会出现。根据MS Connect，当导航关系是双向的（可以访问关系的两个方向）时，将抛出循环引用异常，因此第一件事是禁用关系的一侧。同时，在使用1:1关系（或1:0..1或任何导致创建EntityReference类型属性的关系）时，也会抛出异常，这种情况下的异常将是System.Data.Metadata.Edm.AssociationType类型。
解决方法是使序列化程序忽略类型为EntityReference的属性，使用从JavaScriptConverter派生的空实现类，并使用JavaScriptSerializer对象的RegisterConverters方法进行注册。
3) 导致代码难以测试的有用功能
JavaScriptSerializer的一个有用功能是，您还可以实现自定义JavaScriptConverter并将其传递给JavaScriptSerializer以对序列化/反序列化进行细粒度控制。但是，要使其真正有用，您需要在编译时知道类型并具有对这些类型的引用。这实际上限制了此功能的有用性，因为通过引用这些类，您的代码变得紧密耦合，因此无法轻松地在诸如MVC过滤器之类的东西中使用它。
出于这些原因，我经常使用Json.NET。
希望这有所帮助！
