这个问题描述比较笼统，但根据我目前遇到过两种情况来看，似乎都比较重要而且实用，所以打算分别讲述一下。
说明：Django的版本是Django2.0
第一种：URL配置错误
页面闪一下，却原地不动，可能是下边这种情况。
例如下列连个URL：
re_path(r'^(\w+)/(\w+)/', views.display_table_objs,name="table_objs"),
re_path(r'^(\w+)/(\w+)/(\d+)/change/', views.table_obj_change,name="table_obj_change"),你会发现第二个路由访问请求都毫无作用，但各种调试器查看器服务器控制台等都告诉你“200”，一切正常。
作为一个Django新手，也是一脸懵逼，花了近一个小时终于搞明白，这个问题也是Django新手喷油们常犯的错误。归根结底是正则表达式使用不正确.。上边两个URL只限制了开头，没有限制结尾，所以URL都会在Django算法的作用下直接打开(\w+)/(\w+)/，而如果地址栏已经是(\w+)/(\w+)/的话，自然是“原地不动”了。毫无疑问，Django的算法是一旦找到一个匹配结果就立马显示，这的确是高效的，不需要去遍历所有的URL，但这也产生了以上问题。
解决方案：
re_path(r'^(\w+)/(\w+)/$', views.display_table_objs,name="table_objs"),
re_path(r'^(\w+)/(\w+)/(\d+)/change/$', views.table_obj_change,name="table_obj_change"),加上结束符号“$”，则Django就必须完全匹配方能跳转，则网页运行正常。
第二种：新页面的渲染过程中出现了“不可描述的错误”
我们知道，一旦Django或者Python代码出错，则会立刻反映到页面上，导致程序终止。但是写过前端的朋友一定清楚，无论是JS还是html还是css，都是非常“包容”的语言。简单来说：一点小错，无伤大雅；满篇错误，照样执行。如果不在调试环境下运行，那么任何错误百出的html页面都能“硬着头皮”运行下去。这一点也毫无疑问是有好有坏，好处自不必说，这让前端页面有了极高的容错率和兼容性，这简直是安身立命之本。但是坏处就是，一旦需要加载的页面出现了某些“致命”错误，也不会有报错信息，而是会导致页面莫名其妙地加载或者干脆“消失”。
解决这个问题的方法自然也很简单：完全模拟你要加载的页面（精确到每一个参数，每一个符号），然后在调试环境下独立打开，看看会不会出现一些致命的错误，如果没有，就人工检查一下。错误自然会出现。然后根据错误去修复即可。
如果你的情况类似于这个案例，移步：http://blog.csdn.net/pluschang/article/details/78425523
