1．認為FindControl方法尋找的范圍是給定Control的後代控件。
復制代碼 代碼如下:
<form id="form1" runat="server">
<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
<asp:Panel ID="Panel1" runat="server">
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Button ID="Button1" runat="server" Text="Button" />
</asp:Panel>
</form>
如上面代碼，後台用Panel1.FindControl("Button1")尋找，認為這樣范圍小些可以提高效率，其實即使用TextBox1.FindControl("Button1")也一樣能找到。前有所述，FindControl方法是根據ID在Control所在的命名容器中尋找相應控件。當執行TextBox1.FindControl("Button1")時，ASP.NET先獲取TextBox1.NamingContainer，其值為頁面本身（最後生成的xxxx_aspx類實例），再向下遞歸尋找相應ID的控件，所以一樣能找到Button1。
同樣的，如果用TextBox1.FindControl("Label1")也是能找到Label1的。
2．不理解為什麼this.FindControl方法找不到GridView裡的控件。 其實很好理解，FindControl方法尋找時只在本命名容器下尋找，不會進入其他命名容器中尋找，而命名容器（NamingContainer）不只是頁面本身，還包括GridViewRow、DataListItem、RepeaterItem、UserControl、MasterPage等等諸多控件，這些都繼承了INamingContainer接口，它們的一個顯著特征是其子控件的UniqueID和ClientID一般都不同於ID（除了頂層的頁面對象）。
3．認為FindControl運行效率差。 實際上ASP.NET運行時分析aspx、ascx、master等文件標簽結構，生成類似Dom的控件樹，一般對樹的查詢操作效率還是比較高的，尤其當問題規模不太大時。一般來說，實際頁面裡的控件數量不可能成千上萬，而且尋找時又不能越過本命名容器，這些因素限制了問題規模。所以說FindControl的效率並不差。
